ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
GuzTech has quit [Ping timeout: 240 seconds]
azonenberg_work has quit [Ping timeout: 246 seconds]
azonenberg_work has joined ##openfpga
emeb has quit [Quit: Leaving.]
<azonenberg_work> qu1j0t3: "I can think of people who are capable of detecting this sort of modchip hack. I cannot think of a reason why a due diligence audit of a server would go down to that level."
<azonenberg_work> Yes, i agree with that
<azonenberg_work> i am very curious how these things were allegedly located
<azonenberg_work> I've done pentests of custom hardware to pretty extreme detail
<azonenberg_work> but never a commodity pc mobo
<qu1j0t3> there's really nothing here to grab on to
<azonenberg_work> Yeah
<azonenberg_work> I mean, if i saw fishy network activity or something
<azonenberg_work> that pointed me to dig deeper on a clean OS install
<azonenberg_work> yes, i would keep digging
<azonenberg_work> And i would go down to the hardware if i had to
<rqou> I'm going to be really mad if this turns into badbios v2
<azonenberg_work> rqou: inb4 dragos was their anonymous source
<azonenberg_work> :p
<rqou> azonenberg_work: at some point i want to build some of these implants just for lulz
<azonenberg_work> I think he isn't though, i reached out to him earlier today to ask if he had a line on where i could get some of this allegedly compromised hardware
<azonenberg_work> and he did not
<rqou> I'm sure the media would be thoroughly entertained if we actually implemented this
<azonenberg_work> rqou: me and a coworker built exactly this implant (SPI MITM -> RCE) to break secure boot on [redacted]
<azonenberg_work> Which had a TOC/TOU bug
<rqou> lol
<azonenberg_work> Read flash, compute sha256, calculate rsa signature on it
<azonenberg_work> read flash again, copy to ram, execute
<rqou> lolfail
<azonenberg_work> we cheaped out and just had two flash chips
<azonenberg_work> and muxed CS#
<rqou> heh, classic modchip trick
<azonenberg_work> But a MITM that actively forwarded the data and hex-edited the firmware on the fly is 100% doable
<jn__> [other redacted] has a check signature, jump into flash partition thing, i think
<azonenberg_work> rqou: and if you see my last couple of tweets
<jn__> (i don't have the relevant hardware and haven't dug into enough code yet)
<azonenberg_work> i calculated, based on the size of some of the recent WLCSP16 cortex-m0 MCUs
<rqou> afaik there's no secure boot on the BMC anyways
<azonenberg_work> you can fit 4 KB of flash plus a bunch of SPI and pattern matching logic into an WLCSP the size of an 0402 passive ,comfortably
<azonenberg_work> 4 KB should be enough to patch unauthenticated remote DMA into an IPMI binary
<azonenberg_work> It would need to be an asic, i couldnt find a stock chip like that
<azonenberg_work> But it's technically feasible
<azonenberg_work> Actually, an ice40 ultralite might work for a PoC
<azonenberg_work> Not a ton of storage, but it's a pre-existing solution that could mitm flash
<azonenberg_work> just hex-edit a string or something
<azonenberg_work> 1.4 x 1.4 mm
<azonenberg_work> WLCSP-16
<rqou> azonenberg_work: no otr right now
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
<sorear> could do a rolling hash comparison, and then redirect to a separate wlcsp flash
<azonenberg_work> sorear: yeah i was thinking a single chip
<azonenberg_work> pass through
<azonenberg_work> then when you see the magic byte sequence / hash / whatever
<azonenberg_work> replace the following N bytes from internal memory
<azonenberg_work> then go back to passthroguh
<azonenberg_work> byte sequence vs hash would probably be more stable to small firmware changes
<sorear> Does the UL have internal config flash?
<awygle> you could probably do it with a silicon interposer
<awygle> or other multi die package technique
<azonenberg_work> awygle: yes, and an intelligence agency has that kind of budget
<azonenberg_work> i dont :p
<azonenberg_work> Which is why the PoC would just be a simple string substitution
<rqou> azonenberg_work homecmos when? :P
<sorear> "two stray 0402s" doesn't seem like it would attract that much more attention than "one stray 0402"
<rqou> yeah, we should just build this PoC
<rqou> I'm sure journalists will be amused
<awygle> yes, a UL would be a decent poc
<awygle> somebody add icestorm support
<awygle> it's seriously like an 8h project while simultaneously watching (dubbed) lucky star/ohshc
<rqou> uh
<awygle> sorear: yes, it does
<awygle> have nvcm
<TD-Linux> is there an attiny or something in wlcsp-6
<rqou> not sure, but there is definitely one in sot23-6
<rqou> so you can probably special-order it if necessary
<TD-Linux> why am I asking when I have digikey to answer all my questions
<awygle> I feel like if you're restricted in memory you can get more done with an fpga than a processor
<awygle> based on essentially nothing
<TD-Linux> microcontrollers have embedded flash
<TD-Linux> which automatically makes them way more suited to this
<rqou> iirc attiny is kinda a pain to set up for mitm
<rqou> you can definitely pull it off though
<rqou> i don't remember if it has a slave-mode SPI controller
<rqou> some of them are master only and hacked onto a uart
<TD-Linux> you could even bitbang it. I don't know how critical speed is
<TD-Linux> I know intel me flash is pretty fast, but dunno about bmc flash
<azonenberg_work> TD-Linux: well you would have to mitm the bus
<azonenberg_work> so you have to run at the same speed as it
<azonenberg_work> (you have no control over sck)
<TD-Linux> true
<azonenberg_work> i was thinking a tiny fpga that just hot-patched a few bits of flash
<azonenberg_work> the real implant would be an asic
<azonenberg_work> that had multiple hard spi, a pattern matching engine, and flash for payload
<rqou> yeah, the ME bus runs at like 100 mhz
<rqou> it'll fail if you have too many hackwires on it :p
s_frit_ has joined ##openfpga
s_frit has quit [*.net *.split]
balrog has quit [*.net *.split]
WilhelmVonWeiner has quit [*.net *.split]
SpaceCoaster has quit [Ping timeout: 252 seconds]
balrog has joined ##openfpga
WilhelmVonWeiner has joined ##openfpga
SpaceCoaster has joined ##openfpga
genii has quit [Read error: Connection reset by peer]
<azonenberg_work> TD-Linux: i tweeted that part a while ago as a plausible example
<azonenberg_work> not that i would build an implant with it
<azonenberg_work> but that it was pretty small and had plenty of flash
<azonenberg_work> thus proved you COULD build an implant asic a quarter of the size with 4KB of flash, two lanes of fast spi, and some sophisticated patter nmatching
<sorear> how much ram?
<azonenberg_work> the mcu has 32kb flash and 8kb ram
<azonenberg_work> Extrapolating down and assuming most of the die is memory and the CPU is pretty small
<azonenberg_work> all of the stuff you need for a pretty sophisticated implant would fit in a die the size of an 0402 passive
m4ssi has joined ##openfpga
<kc8apf> BMC flash is 50-60Mhz iirc
<kc8apf> It will work down to 20 or so unlike Intel chips that have a narrow window
<azonenberg_work> kc8apf: yeah but you cant force the bmc to downclock right?
<azonenberg_work> you have to live with whatever SCK it provides
<azonenberg_work> there's no stretching capability
<azonenberg_work> So as a MITM you deal with that
<kc8apf> Keep in mind that both Google's Titan and Microsoft's Project Cerberus are MITM in exactly this way but to enforce integrity
<zkms> kc8apf: how do you mean, what's MITM'd by what?
<kc8apf> azonenberg_work: depends on the BMC. Aspeed speed is externally strapped. Nuvoton starts at a slow speed to read a config from flash that sets correct speed
<kc8apf> zkms: Titan and Cerberus sit between host CPU and BIOS flash and/or BMC and BMC flash
<kc8apf> Reads are untouched but writes are filtered and signature checked
<azonenberg_work> kc8apf, zkms: well i personally was talking about a hypothetical backdoor chip
<kc8apf> Both also are tied into reset and can prevent CPU from booting until flash signature has been verified
<azonenberg_work> that sat between the BMC and BMC flash
<azonenberg_work> and tampered with the IPMI firmware on the fly
<zkms> kc8apf: ahh ok.
<kc8apf> azonenberg_work: right. Titan and Cerberus are real examples of MITM for a different purpose
<kc8apf> They demonstrate it is possible to MITM reads at normal BIOS bus speeds with careful coding on custom micros.
<azonenberg_work> yeah, that much i knew already
<azonenberg_work> i assumed an implant would be an asic just to cut die area and make it more concealable
<azonenberg_work> i mean there might be an arm core
<azonenberg_work> But it would be a custom die without extra bond pads bulking it up
<kc8apf> I'd be surprised to see it at the "tip of pencil" size
<azonenberg_work> My math says it can be done
<azonenberg_work> 2x3 ball WLCSP, 0.35mm or so
<azonenberg_work> or equivalent
<azonenberg_work> What threw me off in this case was that it looked like some kind of ceramic filter
<azonenberg_work> Putting an IC inside a ceramic package without visible seams would be hard (unless it isnt actually ceramic)
GuzTech has joined ##openfpga
<azonenberg_work> as sintering the ceramic normally requires high temperatures that the die wouldnt survive
<kc8apf> Ugh. I screwed up this FTDI design. I followed the bus-powered reference design but I have self-powered txd/rxd.
<kc8apf> So when the cable is unplugged from USB, it draws from the txd/rxd and they hold at odd levels
<kc8apf> I'm quite certain the photos are of a random part
<azonenberg_work> You dont think they have anything to do with the actual implant?
<azonenberg_work> (if there even is one)
<whitequark> azonenberg_work: marcan had some guesses on twitter
<kc8apf> The server boards might be
<azonenberg_work> oh? didnt see that thread
<kc8apf> qrs found a clear shot of the area on the board where the implant was claimed to be found
<whitequark> azonenberg_work: apparently the real SM boards have some kinda magnetic soldered on top of a SO-8
<whitequark> which is... lolwhat?
<whitequark> i see how that would be *ideal* for an implant
<kc8apf> It was on an alternate footprint for one of the flash parts
<marcan> my current working theory is they got told they "looked like a signal conditioning coupler" and googled that and stumbled upon ceramic RF couplers
<marcan> and made up all the photos and details around that
<marcan> but *this* is also something that fits that description, and *actually* can be found on server motherboards, and it would be trivial to make an SO-8 masquerade as it: https://twitter.com/marcan42/status/1047938864579469312
<kc8apf> A bit hard to tell if it was BMC or host flash though.
<marcan> kc8apf: BMC
<marcan> I did the research on that
<marcan> the big chip is always BMC on supermicro mobos, they always have that pattern but on some boards they're on opposite sides
<marcan> this makes sense, because the BMC needs a lot more flash
<kc8apf> Right. It was a 256Mb part but that board is spec'd for 128Mb host flash
<marcan> yup
<azonenberg_work> side note
<kc8apf> Just some of the traces went off oddly
<azonenberg_work> If the BMC flash is physically removed
<azonenberg_work> What happens?
<marcan> depends on the design
<kc8apf> Not much
<azonenberg_work> does the board still boot and post and you just lose IPMI?
<azonenberg_work> or is it bricked
<marcan> some systems pass through the BIOS via the BMC
<marcan> those will definitely be fucked
<marcan> some don't, and then I guess it depends on how coupled the BMC is with the boot process
<marcan> I know for a fact (some) Dell servers will reboot, but hang, if the BMC is wedged
<azonenberg_work> case in point: i have a supermicro box that i don't use IPMI on
<azonenberg_work> And it has a socketed soic flash next to an aspeed bmc
<marcan> SOIC8 or SOIC16?
<azonenberg_work> 16 iirc
<marcan> sounds like BMC flash, try it and tell us? :)
<kc8apf> Intel reference designs use an external mux for host flash arbitration and power/reset signals get put through a clever loopback GPIO bank on the BMC
<azonenberg_work> well there are two socketed flashes
<azonenberg_work> one near the cpu area that looks like a bios
<marcan> yeah
<azonenberg_work> this one looks ike its for the bmc
<marcan> it seems supermicro boards sometimes have sockets and sometimes don't
<azonenberg_work> its a cm or so away
<marcan> yeah
<azonenberg_work> This is an x11dai-n
<azonenberg_work> if memory serves me right
<azonenberg_work> you can see the two sockets
<marcan> I see two SOIC16s on that one
<marcan> so yeah
<marcan> I'd say give it a shot :)
<azonenberg_work> Given the massive distance from bmc to bios flash
<kc8apf> Quanta follows Intel designs closely. Those will boot just fine with a bricked BMC
<azonenberg_work> i conjecture bios doesnt go throguh it
<marcan> yup
<azonenberg_work> the system is in a box right now during my move
<azonenberg_work> But even if this whole thing turns out to be nothing
<azonenberg_work> I will probably try pulling the bmc flash since ipmi is just another bit of attack surface
<marcan> yeah, if you don't use the BMC and there is no impact, no reason to have that thing alive
<azonenberg_work> if it boots i'll leave it off
<azonenberg_work> i forget server mobos have all that stuff in them :p
<kc8apf> That looks like a classic Intel reference design
<marcan> I'm glad they do, it means I can server-admin a LAN party from halfway across the world via a 3G VPN :P
<azonenberg_work> marcan: lol
<azonenberg_work> meanwhile i am planning to, for unrelated reasons
<kc8apf> There's probably a cpld somewhere that has the mux in it
<marcan> except when a server randomly dies
<marcan> as it did this time >_>
<azonenberg_work> there is a lattice cpld
<marcan> refuses to even start to POST
<kc8apf> That's the one
<azonenberg_work> i think a machxo?
<kc8apf> Intel loves that
<marcan> speaking of server admin, just for the record, you can fully license Avocent/HP KVM network switches for KVM-over-IP with.... developer tools.
<kc8apf> It has the BIOS SPI mux and some glue logic around power up signals
<azonenberg_work> marcan: anyway i am planning to lock down my new lab to the point that the internal R&D network has no internet access whatsoever, except possibly ssh to github or a few other whitelisted locations
<marcan> let's just say they have a "touch a file to fully license" backdoor, and an incredibly insecure PHP interface with an obvious endpoint that has a path traversal vuln
<azonenberg_work> lolol
<azonenberg_work> i already had it set up so that email, irc, general browsing, online banking, and social networking lived in separate VMs on another box
<kc8apf> So, yes. It should boot without the BMC. It will probably drive the fans at full speed though
<azonenberg_work> so all i have to do is add a firewall rule to block all outbound traffic from the R&D vlan except TCP 5900 to the DMZ
<kc8apf> Probably could get OpenBMC up on it pretty quickly though
<marcan> yeah, that's a classic
<marcan> no BMC -> jet engine mode
<marcan> well, more like, *anything goes wrong* -> jet engine mode
<marcan> ah, servers.
<azonenberg_work> kc8apf: i dont want openbmc, the thought was that if there is such an implant on the thing
<azonenberg_work> if it has no firmware to patch
<azonenberg_work> the implant probably is neutered
<azonenberg_work> i doubt it has enough memory to duplicate the whole ipmi stack
<azonenberg_work> it just hot-patches a little bit
<kc8apf> OpenBMC without a gpio map can still run the fans
<azonenberg_work> So if the BMC is stuck in reset, any screwing with the spi bus wont hurt me
<kc8apf> Openbmc and AMI MegaRAC are worlds apart
<azonenberg_work> i guess it probably wont be binary patchable at that point, but still
<marcan> you could just write protect the flash
<marcan> at least then there's no persistence
<kc8apf> Hot patching ipmi is complicated in both cases
<azonenberg_work> marcan: i dont think it writes to flash
<marcan> oh you mean if there's a chinese style mitm implant
<marcan> sure
<azonenberg_work> this is likely just a "pass through all reads except 0xfoo - 0xbar"
<kc8apf> Meh. Just use the OpenBMC kernel and use your BMC as an extra server
<azonenberg_work> exactly
<marcan> but I highly doubt those would survive a complete swap to openbmc anyway
<marcan> kc8apf: :D
<azonenberg_work> yeah but holding the bmc in reset is easy, safe, and effective :p
<marcan> if you're okay with jet engine fans :P
<azonenberg_work> i dont actually know what the state of the fans on that box is
<azonenberg_work> how loud, how many, etc
<azonenberg_work> the UPS drowned them out most of the time
<marcan> if it's anything like all the servers I've used, it's a fucking jet engine by default until the BMC figures out the sensors and fans work and it can go into sane mode
<azonenberg_work> with its beefy fans (online double conversion fairly well loaded)
<marcan> and then how loud sane mode is... varies widely between brands
<azonenberg_work> This is a workstation
<azonenberg_work> so a big tower case
<marcan> but the bootup state is universally fucking loud
<marcan> that might be slightly different then
<azonenberg_work> i do know that i had one 4U system years ago that i ran for my professor
<azonenberg_work> i swear the reason it was so slow to POST is that it was radioing Albany Tower for takeoff clearance
<kc8apf> Just don't run the host CPUs with a BMC firmware that doesn't set the PROCHOT GPIO to a known state
<marcan> is that all there is to it?
<azonenberg_work> i had it running onpen on my desk to test
<marcan> what actually does fan mgmt?
<kc8apf> BMC
<azonenberg_work> It blew papers off a desk on the other side of the room
<marcan> so then without any BMC code they'd default to full, right?
<marcan> btw: my Threadripper motherboard has an inline switch for PROCHOT :D
<marcan> MOAR OVERCLOCKING
<kc8apf> Only if external hardware is there to drive them fill when the pwm is missing
<kc8apf> PROCHOT is a different story. It's just a GPIO that the BMC drives. If left floating, odd things happen
<marcan> is that the throttling thing?
<kc8apf> Yup
<marcan> is it an open-drain bus?
<marcan> I seem to recall it being an I/O or something
<marcan> yeah some random intel doc says it's bi-directional
<kc8apf> Intel has PECI to ask about temps and power
<marcan> yup
<kc8apf> AMD added a similar thing on threadripper
<kc8apf> Previously AMD just have you a diode
<kc8apf> Anyway, all temp sensors go to the BMC over i2c. BMC has dedicated fan tach+pwm peripheral to manage 12 or so fans
<kc8apf> Mainline kernel has drivers my team wrote for that and other wonky BMC peripherals
<marcan> neat
<kc8apf> Time for bed
<TD-Linux> I'm still trying to figure out cool things to do with my server that has openbmc
<TD-Linux> marcan, lol is that what that is? my asrock threadripper board has a switch on top that was apparently overclocking related
<marcan> yeah, lol
<TD-Linux> the threadripper is the first time I've built a desktop since 2005 and a lot of stuff is different
<TD-Linux> it also seems to turn on/off/on in first start when standby power is removed. not sure what's up there
<Prf_Jakob> TD-Linux: My Intel workstation does the same, seems to be something workstation MBs do.
<keesj> we talked about this before. why would I source or drain my leds from the FPGA?
<whitequark> keesj: context?
iximeow has quit [Quit: Lost terminal]
<TD-Linux> usually cmos drivers can sink more current than they can source
<keesj> well I am still working on my 20 leds project driven by an fpga. the current of the leds will be 2mA and the buffers of the choosen FPGA can handle 8mA. I am wondering if I should let the FPGA drive the leds (e.g. put the anode on the FPGA or use the FPGA to sink the current)
<whitequark> sure, that's fine
<keesj> I think.. I need some context now. what is fine? TD-Linux appears to say it would be "more better" to sink
<whitequark> in your case it makes no difference
<TD-Linux> ^
<whitequark> TD-Linux: btw I haven't seen asymmetrical CMOS drivers in a while, i think people just make one FET larger now?
<whitequark> not according to datasheets anyway
<TD-Linux> whitequark, yeah I guess that would make for high speed data lines
iximeow has joined ##openfpga
<keesj> ok I will pick one
<TD-Linux> now that you mention it, the last time I remember this on a datasheet is ye olde PICs
<TD-Linux> *asymmetrical max currents
<whitequark> TD-Linux: i remember that standard cells all now use asymmetrical FETs from talking to azonenberg i think?
<whitequark> and i've looked at currents too
<whitequark> so that's a logical conclusion
<TD-Linux> it makes sense from an engineering point of view, if you're limited by slew rate you'd want them to be equal
<TD-Linux> and likewise if you are using a slower slew rate for EMI you still want them to be equal
<whitequark> yep
<TD-Linux> box of glasgow parts is here
<TD-Linux> think I'm going to print out the bom on paper and tape parts to that to mail them out
<whitequark> sweet
<zkms> nice
<whitequark> TD-Linux: how many people did eventually want one
indy has quit [Read error: Connection reset by peer]
<TD-Linux> 4. which is great because I ordered 5
<whitequark> right, i guess not that many people want to assemble smt
<TD-Linux> probably a lot more would like preassembled ones, but I wasn't willing to do that many
<whitequark> understandable, i think it's a pain in the ass too
<TD-Linux> maybe when I finally put together a reflow oven
<whitequark> just... need to iterate to revC
indy_ has joined ##openfpga
ondrej3 has left ##openfpga ["Leaving"]
<TD-Linux> if you want to shill revc a bit harder, including it in pictures when you re stuff would help :)
<Ultrasauce> ya i'm down for an assembled one when one of you does a run
<Ultrasauce> unassembled is a bit too much of a ~project~ rn
<zkms> how do i assemble one of those
<TD-Linux> I'll livestream assembling mine on tuesday when the pcbs finally arrive
<keesj> all sounds cool
<TD-Linux> I don't think it'll be too hard though. the passives are 0603 with the fat kicad pads
<whitequark> TD-Linux: revC doesn't exixst yet
<whitequark> TD-Linux: yeah i specifically chose the hand soldering footprints
<TD-Linux> whitequark, yeah I know
<TD-Linux> yeah. they are excessive for 0805 but nice for 0603
<whitequark> awygle: can we add pullups on every pin for revC?
<whitequark> maybe 10k...
<whitequark> just so you can plug in i2c and have it "just work". not even very fast, just some degree of work
<whitequark> awygle: seems like it'd need a FET and a resistor, because of Vio
<whitequark> pulldowns would be easier but there are tons of interfaces with open-drain pins
<whitequark> and i don't recall any i wanted with open-source
<whitequark> ... open-source lol
<TD-Linux> it feels like there should be level translators with that built in
<whitequark> hell no
<whitequark> level translator landscape is kind of desolate
<whitequark> we have exactly one we can use on revC
<whitequark> in the entire semiconductor industry
<TD-Linux> rip
<TD-Linux> btw I didn't put any delays on my 74lvc245 direction pins and it seems to work "fine"
<TD-Linux> should probably scope the power though at some point
<whitequark> oh sure, transients like that wouldn't be easily visible
* TD-Linux is maybe a bit cautious from working on 20kw motor drives where those were... quite easily visible (and audible)
<Ultrasauce> what's a little crowbar among friends
<s_frit_> TD-Linux: what is this board you are making?
<s_frit_> (just curious)
<s_frit_> TD-Linux, neat.
<TD-Linux> next project after this might actually be a motor controller
<TD-Linux> got a torque transducer, motors, vescs, and some v-rail is on the way. ever wonder if ultra cheap hobbyking rc motors meet their specs? now I'll know
<s_frit_> In what world are these C-Bus cards used? Is there another name for the form factor? i'm having trouble googling
<TD-Linux> s_frit_, your "in what world" intuition is pretty good. https://ja.wikipedia.org/wiki/C%E3%83%90%E3%82%B9
s_frit_ has quit [Remote host closed the connection]
s_frit has joined ##openfpga
keesj has quit [Ping timeout: 252 seconds]
keesj has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
SpaceCoaster has joined ##openfpga
Bike has joined ##openfpga
genii has joined ##openfpga
scrts has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
scrts has joined ##openfpga
emeb has joined ##openfpga
GuzTech has quit [Quit: Leaving]
m4ssi has quit [Remote host closed the connection]
Miyu has joined ##openfpga
bcoppens has joined ##openfpga
renze has quit [Ping timeout: 246 seconds]
renze has joined ##openfpga
Maylay has quit [Quit: Pipe Terminated]
Maylay has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
Hamilton has joined ##openfpga
Maylay has quit [Quit: Pipe Terminated]
mumptai has joined ##openfpga
Maylay has joined ##openfpga
Bike has quit [Ping timeout: 256 seconds]
grantsmith has quit [Quit: ZNC - http://znc.in]
grantsmith has joined ##openfpga
grantsmith has joined ##openfpga
grantsmith has quit [Changing host]
Bike has joined ##openfpga
Hamilton has quit [Quit: Leaving]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
oeuf is now known as the_void
the_void is now known as oeuf
rofl__ is now known as jcarpenter2
<TD-Linux> awygle, can you assign me 6 serial numbers
<whitequark> TD-Linux: no need to
<whitequark> `glasgow factory` does that
<TD-Linux> nice
<whitequark> :3
<awygle> whitequark is very good at softwarez
<whitequark> did... did the fab put a pcb number into the "serial number" field
<whitequark> can they please not lol
<TD-Linux> yeah :^)
<TD-Linux> I'll cut out a sticker over it anyway. don't have anything that writes in white
<awygle> who did you fab with?
<awygle> TD-Linux: what's your schedule like? you might finish testing before i do... >_>
<TD-Linux> awygle, probably going to put them together in about an hour
<TD-Linux> well, one
<TD-Linux> will livestream
<awygle> yeah i won't even be home yet, cool. lmk how it goes!
<Zorix> what is it?
<Zorix> very nice, thanks
<prpplague> usually you can add a note in the fab drawing as to where they can/can't put fab numbers on the silkscreen
<prpplague> most of the time it isn't really an issue, but certainly putting it in a serial number box is annoying
<awygle> TD-Linux: who'd you use for the fab? i feel like you told me this once and i forgot
<Zorix> apparently if you use jlc if you put a text saying jlcjlcjlc somewhere on the board they will use that
<awygle> that's cool. if it's per-board and not per-panel i'd happily let them serialize my boards for me.
<whitequark> TD-Linux: ok so if you want to assign serials without assembling the board
<whitequark> you can do `glasgow factory --help`
<whitequark> that just generates a new serial as text
<whitequark> when it's assembled you give it as --serial=
<whitequark> awygle: so i had an evil idea
<awygle> whitequark: oh goody
<TD-Linux> awygle, pcbway. it's only the 2nd time I've used them, and 1st for 4 layer
<whitequark> i should put a ECC secure element on the board, and state in the repo that only support requests signed with the board serial number with the secure element certificate get free support
<prpplague> TD-Linux: is that your twitter account?
<TD-Linux> yes
<whitequark> if you made a board yourself but want support from me, you can get a support key or something
<TD-Linux> you're making a critical mistake here
<prpplague> TD-Linux: yea, if you put in the comments section when you order at pcbway, you can tell them where they can/can't put the manufacturing fab number
<TD-Linux> and that's offering support
<whitequark> well
<whitequark> depnds on the cost?
<prpplague> TD-Linux: what's the system you are doing the c-bus joystick for?
<TD-Linux> pc-98
* prpplague is not familiar with that
* prpplague seachers
<awygle> whitequark: i am not opposed to this in theory but have some practical concerns. in particular, which ecc secure element, and is there documentation for it
<gruetzkopf> for me they've always worked out good positions on their own
<gruetzkopf> like under big DIN connectors
<whitequark> awygle: yes
<whitequark> atmel makes ATECC which is about $1
<whitequark> and it is fully documented
<rqou> why bother with all this?
<awygle> oh, cool
<prpplague> TD-Linux: nec pc-98?
<whitequark> rqou: don't wanna do free support
<awygle> (microchip nee atmel)
<TD-Linux> prpplague, correct
<rqou> just don't do support?
<prpplague> TD-Linux: ahh dandy
<whitequark> if you got a board from me, you automatically "support further development", which is proven by the ECC chip
<rqou> hmm i guess
<whitequark> if I decide not to bother, idk, can just not populate it? another piece of junk on I2C
<TD-Linux> prpplague, probably best known for the first 5 touhou games
<whitequark> big deal
<rqou> oh it's i2c
<whitequark> sure
<rqou> not serial smartcard
<whitequark> it's real easy to use
<whitequark> lol no
<whitequark> i think i can make it work in a day or two tops
<awygle> same difference really
<rqou> yeah whatever then
<awygle> whitequark: are you sure this is documented? i don't see like, a command set
<gruetzkopf> throw on a SIM800E and M2M sim :P
<rqou> inb4 china totally knows how to clone atecc chips
<TD-Linux> as cool as the ecc chip idea is, I still think signed serial plus online "scratch off" is more practical if you want to achieve that
<rqou> gruetzkopf no
<gruetzkopf> still need to play with the reclaimed sim800 we have around
<whitequark> TD-Linux: i don't want to run any secure infra
<whitequark> i want atmel to do that for me and i want to not have a website
<whitequark> p sure this is worth $1 per board
<whitequark> further, if anyone *else* wants to do the same, they don't need like, another website
* whitequark shrugs
<prpplague> TD-Linux: pcbway is my "go-to" place for non-mission-critical prototypes
<TD-Linux> I have friends that have had good luck with really weird pcbs from them.
<TD-Linux> like 200mmx2mm
<prpplague> oh interesting
<TD-Linux> LOL some city of glasgow twitter bot retweeted me
<awygle> yeah we hit that before lol
<prpplague> TD-Linux: that's pretty cute
<TD-Linux> have you had any thoughts about logic analyzer mode? emulating fx2 logic analyzers?
<whitequark> TD-Linux: i think i want a logic analyzer mode for debugging applets
<whitequark> so that'd emit an uhhh
<TD-Linux> so not emulating a fx2 one
<whitequark> VCD file with i, o, and oe triples
<whitequark> for every pin and also glasgow usb pipes
<whitequark> sort of pain in the ass to implement because i'll need compression but like, ok
<TD-Linux> well compression would be great to have
<TD-Linux> fx2 should be fast enough to do it in software?
<whitequark> BAHAHAHAHAHA
<whitequark> fx2 is fast enough to do precisely nothing in software
<awygle> whitequark: LXT2 and the other one plz
<whitequark> it can't even copy data fast enough to put a few Mbps through USB
<awygle> FST
<awygle> wait "GHW" what fresh hell is this
<TD-Linux> why is it so expensive then
<whitequark> ghw?
<awygle> oh GHW is the VHDL one
<awygle> nvm
<whitequark> TD-Linux: well it does most of the horrible USB things in silicon
<whitequark> and it's really fast if it just copies data to the external bus
<whitequark> like easily saturates USB2
<whitequark> FX3 doesnt quite saturate USB3 i think
<whitequark> which is weird
<TD-Linux> I guess hardware rle
<whitequark> it can only do about 3 Gbps
<TD-Linux> actually hardware arithmetic coder
<TD-Linux> because we're not plebians
<whitequark> uhhhh idk UP5K isn't super large and i like fast PAR
<whitequark> i can pause the applet anyway if the LA gets stuck
<whitequark> this will break timing-sensitive stuff but like... use a real LA for that i guess? sorry