<fridtjof[m]>
My device was in the march 2024 batch with the modified design flag set - is running glasgow factory to fix that alright re: warranty/support?
Wanda[cis] has joined #glasgow
<Wanda[cis]>
fridtjof[m]: are you using the most recent version of the software? we have a workaround that should detect the affected devices
<fridtjof[m]>
oh yeah i'm aware of that, this is purely for aesthetic reasons to not make it show up as "Another Interface Explorer"
<whitequark[cis]>
lmfao POSIX is even worse than I thought
<whitequark[cis]>
> If the first line of a file of shell commands starts with the characters #!, the results are unspecified.
<whitequark[cis]>
this is amazingly useless even for POSIX
<Attie[m]>
heh, intriguing
<Attie[m]>
I've definately seen/used #!/bin/bash -eu a bunch in the past, and looking at the error, it seems that what you linked may be a /usr/bin/env thing(?) ... i.e: use -S, which is also icky
<Attie[m]>
it's like the mangling you get trying to put args with spaces through ssh
<Attie[m]>
sigh
<whitequark[cis]>
hm? no, it's not a /usr/bin/env thing.
<whitequark[cis]>
the kernel does not split the arguments at all
<whitequark[cis]>
you get "stuff before first space" which is the thing it launches, and "stuff after first space" which is what it gets as argv[1]
<whitequark[cis]>
want to do something more? get fucked, says Linux
<whitequark[cis]>
yes, this is unbelievably bad even by the already low bar of unix software
<Attie[m]>
oh you're right.......!
<Attie[m]>
yup, yuck
<whitequark[cis]>
env includes a workaround for that garbage behavior practically since 2020 or so
<Attie[m]>
yeah, i see now - how did I not know / realise this before?!
<whitequark[cis]>
most people never encounter it because they copy the shebang line from other scripts
<whitequark[cis]>
and basically every script uses either /usr/bin/env x or something like /bin/bash -ex
<Attie[m]>
i guess it's a lazy way to get around any handling of quotes/escapes in the kernel
<whitequark[cis]>
it is
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]>
[redacted] tells me to ask you to use /usr/bin/env bash for nixos compatibility
<whitequark[cis]>
* [redacted] tells me to ask you to use /usr/bin/env bash (for nixos compatibility or something)
<Attie[m]>
heh, love the edit
<Attie[m]>
and noted, ty
josuaH[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[m]>
using glasgow with the default wiring harness that has 20 cm wires is an incredible crash course in digital signal integrity
<whitequark[m]>
especially at higher pin counts (even SPIx4/quad-SPI) it has a very noticeable amount of crosstalk and you will encounter crosstalk related issues that will make no sense and will not be visible on a scope because connecting a scope makes them go away
<whitequark[m]>
and, being a persistent little kitten, i have developed incredibly cursed adaptations to this. for example, the signals that are by far most susceptible to crosstalk are async controls (for SPI, SCK; for ONFI NAND, WE#/RE#; for Ethernet, TX_CLK) and the best way to mitigate that (i mean aside from Actually using things correctly) turns to twist the async control signal with a ground
<whitequark[m]>
(there are other ways, for example inline slew rate limiting resistors, but i'm tired and exhausted and i don't wanna solder or anything)
<Attie[m]>
interesting to hear, doubly frustrating when you're only looking at a digital trace too
<Attie[m]>
well done for getting things (QSPI / Ethernet) so robust despite this
<joshua_>
oh that makes sense. I think maybe less crosstalk and more non-monotonicities make clocks / async control signals angry
<whitequark[cis]>
non-monotonicities?
<whitequark[cis]>
Attie[m]: weeeeelll they're only robust if you protect the victim signals
<whitequark[cis]>
the janky wiring harnesses i've been using are all using the "twist the victim with gnd" trick
<whitequark[cis]>
otherwise ethernet gets random nibble shifts after your data goes from 0 to F
<joshua_>
i.e., crosstalk comes from an aggressor signal, but if there is a reflection on a single signal, then the clock can bounce around the threshold voltage
<whitequark[cis]>
what's really funny is that twisting the only ground for the ethernet (signal/power ground) with TX_CLK was still good enough to make the BER very low
<whitequark[cis]>
like, so low it's not measurable with my normal setup
<whitequark[cis]>
joshua_: it's possible, but i have no way to validate it really
<joshua_>
I think the other lesson that I have learned from these sorts of shenanigans is that modern PHYs are extremely robust and you can get away with a lot
<joshua_>
also it is somewhat surprising to me that a (high impedance, hopefully?) scope probe makes it go away
<whitequark[cis]>
my understanding is that (a) the extremely fast edges of SN74LVC1T have lots of high frequency content and (b) the scope probe acts as a sort of makeshift filter for those
<whitequark[cis]>
like the R and C parasitics of it do
<whitequark[cis]>
but this is incredibly handwavey and i honestly don't know
<joshua_>
the probe itself may cause its *own* reflections, with bad grounding -- or if you have your probe set up as 1x instead of 10x it also will change things some
<joshua_>
'changing things some' IME is often sufficient to make problems go away
<joshua_>
oop strong language at the end of that video
<joshua_>
a transmission line probe in this case also would potentially 'change things some', though it would be a 500 ohm load at least instead of a 50 ohm load
<joshua_>
which reminds me, I will try to run your pulse generator later today and see what I can see
<josHua[m]>
I started with some intentionally poor probing technique to get a baseline. this is clearly above the bandwidth of my probe; I am using a Rigol RP3500A 350MHz passive 10x probe connected to a 800MHz-capable DHO4000.
<josHua[m]>
rise time is definitely more than 300ps. 10-90 rise time is about 1.35ns but seems to be slew rate limited (and arguably is not measured here, because 2.4V is way below a 90% rise)
<whitequark[cis]>
oh I see, 1.35 is still quite good
<whitequark[cis]>
(and for the task at hand, 2.4V is enough, since you can use that to trigger a FET to glitch a target)
<joshua_>
let me try with littleprobe, though
notgull has joined #glasgow
notgull has quit [Ping timeout: 255 seconds]
hysiact[m] has quit [Quit: Idle timeout reached: 172800s]
<josHua[m]>
into 500 ohms, 750ps rise time, much better waveform shape. the bimodal pulse width is kind of interesting and I wonder where it comes from
<josHua[m]>
(I originally did this with a chopped-off littleprobe, but something was shorted in there for reasons unknown, so I took the cheap-ass littleprobe and made it even cheaper-ass https://photos.app.goo.gl/JgBokfwfCMTNig2K9 )
<josHua[m]>
into 50 ohms it has a similar shape but cannot quite seem to drive up to 3v
<josHua[m]>
anyway, this was nice reward candy for hooking up my actual work project, which I should go back to now. if anyone has ideas as to what that bimodal pulse length is about I am all ears
<whitequark[cis]>
oh, probably related to the janky way in which the delay line race is constructed
<whitequark[cis]>
it might be that one of them is a posedge pulse and one is a negedge pulse (iirc it pulses on both)
<whitequark[cis]>
(since it's a xor so it's symmetric)
<whitequark[cis]>
i assume negedges are slightly faster than posedges or something
<joshua_>
oh, yeah, it is set up such that it is xor, not posedge only
<joshua_>
so indeed presumably the LUTs (and routing buffers...?) have different delay internally depending on how well matched the CMOS transistors are
redstarcomrade has quit [Read error: Connection reset by peer]
<joshua_>
if the mechanical setup were not so jank (and I were not desperately trying to do other things) I would experiment more with this
<whitequark[cis]>
nod nod
<josHua[m]>
I guess what I am really saying is that esden (@_discord_269693955338141697:catircservices.org) needs to manufacture some littleprobes (though probably with some mods, like a stiffener) and put them in the 1b2 store as a public service to hobbyists who otherwise would think that extremely expensive 10x passive probes are what they want, so that nobody ever has to deal with odd behavior from 10x passive probes ever again