<ZirconiumX>
Just to clarify something from the README: "Glasgow is a 50 MHz bus multitool" but "he PC interface has peak throughput of ~360 Mbps (bulk endpoints), so you can sample 16 channels at 22.5 Msps, 8 channels at 45 Msps, 4 channels at 90 Msps, and so on"
<ZirconiumX>
So, the 50 MHz value is not the sampling rate?
<whitequark>
ZirconiumX: that depends on the protocol implemented in gateware!
<whitequark>
so if you stream each single sample of raw pins, you're bandwidth limited
<whitequark>
but it's possible to e.g. compress samples.
<whitequark>
there
<whitequark>
*there's already an onboard logic analyzer for applets that does compression, and it can easily sample 16 channels at 16 Msps, but with certain restrictions (that are usually satisfied anyway).
<whitequark>
the README is somewhat confusing on that and should be rewritten to something like...
<whitequark>
"the bus throughput is 360 Mbps, and the raw I/O throughput is at least 60 Msps (revB) / 96 Msps (revC) per pin, higher if the gateware was carefully tuned for maximum throughput"
<ZirconiumX>
whitequark: That's...actually really capable for a $70 plus shipping device.
<ZirconiumX>
But I suppose the downside is you need to know Verilog if you want something custom.
<whitequark>
ZirconiumX: Glasgow doesn't use Verilog anywhere
<whitequark>
it uses Migen, which is a kind of abstraction on top of Verilog, though semantically it's more of a Verilog replacement
<whitequark>
using Migen greatly simplifies development of applets
<ZirconiumX>
So it's essentially a Python DSL?
<whitequark>
it is a Python DSL, yes
<ZirconiumX>
You're not even trying to sell it and I'm kinda tempted. Guess I'll keep an eye on this.
<ZirconiumX>
Hey, a figurative blow-up is better than a literal blow-up, though not as exciting.
<gruetzkopf>
most usb ports are only good for magic smoke from silicon
<gruetzkopf>
though with USB-PD at 20V/5A that's definitly changed
<ZirconiumX>
It's still magic smoke
<ZirconiumX>
Just a lot of it
<ZirconiumX>
We have "Beware: it is impossible to simultaneously understand and appreciate USB." as a quote in our rounded corner of the internet.
<whitequark>
hahahahaha, that's excellent
<whitequark>
i know a lot about USB, unfortunately.
<whitequark>
useless serial bus
<ZirconiumX>
(why rounded corner? because there's nothing straight about the people there)
<whitequark>
nice
<ZirconiumX>
I have a....hobby....writing device drivers for Corsair devices.
<ZirconiumX>
Ten different manufacturer specific protocols, and now they're doing an xkcd #927.
<whitequark>
I reverse-engineered a lot of things about Thunderbolt.
<whitequark>
it's even worse than USB.
<ZirconiumX>
But I focus mostly on keyboard/mouse/mousepad/headset.
<ZirconiumX>
How, pray tell, do you get worse than a protocol which has four different transport protocols, descriptors layered in descriptors layered in descriptors and a buggy implementation of half of Common Lisp?
<gruetzkopf>
intₑl
<sorear>
yet, PCIe is fine. we still haven't figured this out
<gruetzkopf>
the actual tech behind tb might actually be (close to) fine, but all of the support firmware and software is delightfully horrible
<whitequark>
yeah
<zkms>
PCIe is good precisely /because/ tsunderebolt is so cursed
<zkms>
there is a conservation law at work.
<whitequark>
ZirconiumX: i counted the firmwares once
<whitequark>
involved in setting up one TBT device
<gruetzkopf>
pcie is extremely good, DESPITE intel working on it
<whitequark>
there are at *least* eight, of which at least three are for the same chip but may differ in versions
<hl>
that's kind of a miracle in itself really
<sorear>
ah, waterbed theory
<ZirconiumX>
I don't know how anybody trusted Intel to design something well from scratch after Itanium.
<hl>
how -did- Intel manage to make pcie not suck
<gruetzkopf>
like, grab the pcie 1.1 spec, read it front to back once and you'll have a good-enough understanding of it
<whitequark>
yep
<gruetzkopf>
like, enough to build devices
<zkms>
they got the people with bad taste in designing these things to work on thunderbolt
<whitequark>
hl: i have been told that in certain™ standards committees there have been people whose only job was to get other people who were known to have bad taste in specifications very very drunk.
<whitequark>
so drunk they could not work on the standard the next day.
<hl>
whitequark: hahahahahaha. oh god. I can believe this.
<whitequark>
and do it every day
<whitequark>
there's also the "sacrificial anode standard design".
<gruetzkopf>
i'd be extremely happy if PCIe had like a 500MT/s mode
<whitequark>
which is when you put in a part of the standard specifically to attract the ire of morons
<whitequark>
and then you remove it with all their changes.
<hl>
whitequark: So a good read (if you're interested in the general principles computer networking, or in the ISO OSI v. TCP/IP war) is 'Patterns in Network Architecture', which I've been reading recently. The author sat on the ISO OSI committee and watched it literally self destruct in political squabbles and dysfunction...
<ZirconiumX>
I am already glad I joined channel
<whitequark>
that's the normal state for committees
<sorear>
ooh I like the sacrificial anode idea, we should have been doing that
<whitequark>
it's surprising if they do *not* self destruct
<ZirconiumX>
My poor, poor sides
<hl>
whitequark: ah yes, the "get rid of the duck" maneuver
<ZirconiumX>
I should probably sleep though; I have a 9am class and it's 1am at the moment.
<hl>
legend about a SW dev boss who would always insist on random (incredibly stupid) changes to SW at the last minute to "put their mark on it", so they started doing things like adding pictures of ducks so that the thing he would say was "oh, and get rid of that duck"
<whitequark>
nice
<gruetzkopf>
next spec on my read list is sRIO
<hl>
what made ISO OSI particularly acrimonious is that it was basically staffed by telco people, rubbing up against this new 'networking' thing; they saw things like connectionless networking and dumb networks and did _not_ like that (moneyyyy)
<hl>
oh god, is this a channel full of people who just randomly read technical specifications? i'm at home
<whitequark>
hl: i implemented the first open-source PCIe PHY
<hl>
whitequark: Wow!
<whitequark>
it's not really usable yet, but it does train the link
<gruetzkopf>
rapidio is nice in that they have their specs like right on their website, without login or anything
<hl>
gruetzkopf: yeah, so I actually collect paywalled technical specifications
<gruetzkopf>
so do we all
<whitequark>
i have a library of those, of course
<whitequark>
i have an entire collection of PCIe specifications up to gen3 as well as a gen4 draft
<gruetzkopf>
my directory of nonpublic datasheets is like 3.5GiB
<whitequark>
including MR-IOV
<hl>
Yeah, I found the gen4 draft too - I've got v0.7. I also have, hold on
<hl>
I have tons of SCSI and ATA standards too, also tons of ISA specs which are mostly public, except for Qualcomm's Hexagon DSP spec
<ZirconiumX>
I, uh, just have the spec sheets for the PS2
<ZirconiumX>
(PlayStation 2)
<ZirconiumX>
Which are very lacking.
<gruetzkopf>
i have not a single hexagon in in pile of trash that i can get code exec on
<gruetzkopf>
i *really* want to play with that monstrosity
<hl>
gruetzkopf: hexagon is hilarious. they literally made an entire DSP arch, and _the only way you can get a Hexagon_ is as part of their ghastly mobile SoCs.
<gruetzkopf>
yep
<gruetzkopf>
i've seen block diagrams of their current SoCs, where they implemented usb-xhci using a hexagon
<gruetzkopf>
instead of nec v850 like nec/amd or whatever intel did
<hl>
hilariously they NDAwall that document on their website, but provide an SDK download for free which is some Windows installer which I had to painstakingly extract to find... the same PDF included within. Good to see corporations continue to have no clue what NDAs are for
<zeiris_>
not *just* mobile SoCs, there's Windows laptops with on-die Hexagon cores now!
<whitequark>
why
<hl>
let me guess, Windows on snapdragon?
<zeiris_>
yup
<zkms>
hl: ty for that Hexagon spec pdf :3
<hl>
zkms: np
<sorear>
gonna pull that in a couple hours when I’m on non-mobile, I collect ISAs too
<ZirconiumX>
You guys ever seen SuperH?
<ZirconiumX>
The ISA.
<hl>
I don't know much about it other than Sega used it a lot
<hl>
Still used in Renesas MCUs IIRC, and someone made that open implementation of it
<ZirconiumX>
Yeah, that and it's sometimes used in cars
<ZirconiumX>
16-bit RISC
<ZirconiumX>
(as in, instructions are 16-bit)
<sorear>
ZirconiumX: yes! #j-core :3
<sorear>
sadly not that active
<ZirconiumX>
https://hwdocs.webs.com/ <--- this website is a gold mine, even if it's hosted on the least trustworthy webhost ever.
<ZirconiumX>
(the actual download links are Dropbox links)
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhppZ
<_whitenotifier>
[whitequark/Glasgow] whitequark 33a63ef - applet..i2c_master: pad scanned addresses to 7 bits.
<hl>
i get wonderful milage out of ddg'ing for "intitle:"Index of"" - random people's open directory listings are so useful
<whitequark>
nice
<ZirconiumX>
From the IBM Gekko (GameCube CPU) ISA manual
<hl>
heh, I had to get used to reading MIPS disassembly recently
<ZirconiumX>
Maybe Alpha would have been a good beginner ISA too.
<hl>
branch delay slots take a bit of getting used to
<ZirconiumX>
Honestly I grokked them pretty quickly
<whitequark>
MIPS is kind of awful though
<whitequark>
I guess the subset people usually teach with is only moderately bad
<hl>
yeah
<ZirconiumX>
I'm talking full fat MIPS 3 here.
<hl>
I mean I assume it's cheaper to licence than ARM or POWER, and now they saw the RISC-V writing on the wall and made it royalty free
<ZirconiumX>
The Great MIPS Schism ISAs are unknown to me.
<ZirconiumX>
And honestly the instruction decoding makes sense. Unlike, say, ARM.
<hl>
ARM is... it may be RISC but it feels hella CISC to me
<ZirconiumX>
ldmia sp!, {pc}
<whitequark>
RISC and CISC are fake terms.
<hl>
more or less
<whitequark>
there's absolutely no point in making the distinction or declaring any core as RISC or CISC, ever.
<hl>
CISC can be viewed as just an instruction stream compression scheme to save fetch bandwidth
<whitequark>
ok, I guess if you want to troll someone on the orange website.
<hl>
and most RISCs have adopted such a scheme out of practicality (thumb, etc.)
<hl>
so everything is a hybrid design now
<whitequark>
no, not even that.
<whitequark>
the distinction was never meaningful to begin with.
<whitequark>
you can't say that something is CISC or RISC because there's no coherent set of criteria.
<hl>
that's true
<whitequark>
you could say that something has a fixed instruction size, or that it doesn't have memory-memory opcodes.
<hl>
the term really relates to a historical trend in ISA design at a particular point in history; it should be viewed as a historical rather than an objective one
<whitequark>
but for example I designed an ISA where registers are stored in a window in main memory. in it, all opcodes are memory-memory opcodes, and also most opcodes are register-register.
<sorear>
RISC means “designed after 1985”, nothing more or less
<hl>
it's basically just a grab bag of New Ideas in non-sucky ISA design that all came to the fore around the same time
<hl>
sorear: pretty much
<whitequark>
lol
<ZirconiumX>
whitequark: what do you consider a "good" ISA? Or do you think there is no such thing?
<whitequark>
that depends on what your domain is
<whitequark>
the problem with MIPS is that it's worse than some other ISA in every domain it's applied in
<whitequark>
it's kind of unique in that
<ZirconiumX>
How so?
<whitequark>
MIPS is an ISA that only has features every other ISA also has, and a set of implementations with absolutely nothing to distinguish them
<ZirconiumX>
I'll admit, they made awful design decisions in hindsight - the separate multiply pipeline, delay slots - but it was still pretty good for its time
<whitequark>
you might have noticed how MIPS gets sold and resold and resold, and that's because no one has any idea what to do with it
<whitequark>
it's just completely pointless
<whitequark>
there's also a thing where it has more than a dozen ABIs
<ZirconiumX>
Modern MIPS, sure, I'm not arguing modern MIPS is any good, because frankly it's not.
<whitequark>
MIPS still doesn't have any SIMD in the spec
<whitequark>
like what?
<ZirconiumX>
MDMX, MSA
<ZirconiumX>
Though I haven't looked at either of those.
<whitequark>
there are a few extensions
<whitequark>
either they are vendor specific, or no real silicon implements them, or both.
<whitequark>
there's absolutely nothing compelling about MIPS. it's not particularly bad, it's just pointless.
<whitequark>
there's no reason to use it over anything else
<ZirconiumX>
Hah, true. The PS2 was really bad in that respect.
<ZirconiumX>
How much do you know about the Toshiba R5900 core used in the PS2?
<whitequark>
basically nothing
<ZirconiumX>
Well, they took an R5000 core
<ZirconiumX>
Cut the caches
<ZirconiumX>
Gave it an integer SIMD instruction set, which uses the same register file as the GPRs, but extended to 128-bit
<ZirconiumX>
Gave it a non-IEEE (DAZ, FTZ, RTZ always on) single-precision-only FPU with changed instruction encoding
<ZirconiumX>
(also there are no NaNs or infinities, instead they just extended the range of valid values)
<ZirconiumX>
Implemented *most* of MIPS 3 but not a 64-bit multiply/divider
<ZirconiumX>
Instead implementing a second 32-bit multiply/divide unit you need to use custom instructions to access
<ZirconiumX>
Gave it a 32-bit virtual address space despite being MIPS 3
<ZirconiumX>
Didn't implement atomic instructions
<ZirconiumX>
And then hooked it up to one of the custom SIMD units they made.
<sorear>
So you have evidence MSA was never implemented?
<ZirconiumX>
Yeah, it's in the P5600 and P6600
<ZirconiumX>
"it" = MSA
<hl>
alright, so, where can I read about this open PCIe PHY?
<hl>
having a SERDES FPGA with an actually open toolchain for the first time is going to be amazing
<whitequark>
yes
<hl>
does the ECP-5G toolchain have functioning SERDES support now?
<whitequark>
yes
<whitequark>
it's ECP5-5G, not ECP-5G
<hl>
er, yeah
<whitequark>
and the -5G suffix is purely binning
<whitequark>
the -5G FPGAs are the normal FPGAs that are overvolted by 0.1V and binned
<hl>
are the SERDES fused off/unusable in the non-5G parts?
<whitequark>
no
<hl>
ooh
<whitequark>
none of the segmented ECP5 devices have any fuses preventing you from treating it as a higher segment
<sorear>
the LFE5UM* parts have a guaranteed 3.3G serdes
<whitequark>
there's a bunch that have larger fabric internally
<sorear>
the LFE5UM5G have guaranteed to 5G serdes
<sorear>
the LFE5U (no M) parts do not have a guaranteed serdes, and it’s not clear if the serdes pads are bonded out on them
<sorear>
xray seems to have been making good progress recently too
<hl>
i've been wondering if you could do SAS on an ECP-5G... seems plausible
<hl>
er, ECP5-5G >_>
<sorear>
dunno much about SAS
<sorear>
there seems to be a small amount of protocol-specific hardware for things like PCIe Electrical Idle
<hl>
yeah
<hl>
it seems like the PCIe, USB3, SATA, SAS, (DP?) PHYs are all absurdly similar to one another, though, really
<sorear>
yeah
<hl>
to the point where Intel's current PIPE spec is 'Converged PIPE' designed to allow a PHY to support all of those as selectable options
<hl>
AFAIK the SAS PHY is really just SATA with a higher voltage level
<sorear>
and there's a "SATA Express" thing now, but I haven't actually read any of the SATA specs
<sorear>
or PIPE for that matter
<hl>
SATA Express is just PCIe
<hl>
probably AHCI over PCIe, I haven't checked - NVMe has pretty much won though
<hl>
the SAS drive connector has been redefined so that it can run (SATA, SAS, or PCIe (for NVMe)), dynamically selecting
<hl>
so SAS backplane controllers are probably going to gradually be replaced with PCIe switches, or hybrid SAS controllers/PCIe switches which can function as either
<sorear>
UHCI, OHCI, EHCI, XHCI, AHCI confused me for a long time (one of these is not like the others)
<hl>
yeah, the generic naming of host controller interfaces is annoying
<whitequark>
hl: USB3 PHY is directly derived from PCIe PHY
<hl>
yep, figures
<whitequark>
the LTSSM has the same state names even
<whitequark>
of course they did not miss an opportunity to fuck it up
<hl>
it's all just LVDS with 8b/10b
<whitequark>
no, also 128b/130b
<hl>
ah yeah. How'd they fuck it up?
<whitequark>
and SAS has 128b/150b iirc
<whitequark>
look at the spec
<hl>
oh god, do I have to
<hl>
even the typesetting of the USB specs sucks
<whitequark>
look, i do not look at the USB spec for free
<whitequark>
you can ask ACPI to give you the VDM data for the altmodes negotiated by the USB C device
<whitequark>
the table is called, fittingly, USBC
<hl>
yeah
<whitequark>
then well, you have to opt into enabling TBT
<hl>
but again, what's nuts is that they did it in ACPI, so how are add-in cards to implement USB-C?
<whitequark>
TBT even has a challenge response auth mode so that you can avoid MITM attacks
<whitequark>
have you seen how TBT3 addon cards work?
<whitequark>
there is a GPIO header
<whitequark>
it's patented, which is how i know what's there
<whitequark>
it's well, there's a pin for taking TBT controller out of power saving mode (yes, it's a sideband)
<whitequark>
and there's another pin for the DP mux
<whitequark>
and some other minor junk, you get the idea
<hl>
yeah, I heard - the chatter in the wake of USB4 caused me to read your IRC logs about TB
<whitequark>
the motherboard has to have a matching GPIO header
<whitequark>
ah
<hl>
right, so it's completely bananas - what I don't understand is why Intel didn't just extend XHCI
<whitequark>
they use XHCI too
<whitequark>
if you daisy chain an USB device to a TBT device, the remote XHCI in TBT device activates
<hl>
ah, but I mean for controlling local USB-C altmodes
<whitequark>
because altmodes aren't USB so much as USB PD which is pretty much completely unrelated
<hl>
intel has chosen a bizarre ACPI-based architecture that assumes all USB-C ports on the system will be on the mainboard, when they could have just added an extension to XHCI for tweaking it
<hl>
hmmmm
<whitequark>
you need USB PD to get USB to work
<whitequark>
the SS inversion mux is controlled by USB PD controller
<hl>
yeah, I saw - USB PD is some 300kb/s serial interface over CC1? Dunno why they didn't just make that serial channel accessible over XHCI
<whitequark>
because altmodes don't involve XHCI at all
<hl>
oh I know, I'm just saying, it would have been saner if they did (or could)
<whitequark>
unsure
<whitequark>
if you tie PD to XHCI, what do you do if your device isn't USB at all?
<whitequark>
like DP over USBC, or something else
<whitequark>
i think the best altmode would have been SGMII over USBC
<whitequark>
what you want for that is probably piping MII registers (if you're terminating that in 1GBASE-T) via USB PD
<whitequark>
since SGMII doesn't have any in-band way to do that
<whitequark>
i mean, there are vendor extensions to do it, and they're horribly insecure, so you don't want htat
<whitequark>
the saner way would be to define a plug-n-play architecture for USB PD controllers in ACPI
<whitequark>
they're like halfway there even
<whitequark>
the PD controllers have a standardized I2C interface
<whitequark>
it's not typically exposed to the OS or ACPI, it's EC/TBT controller only
<whitequark>
probably because you jammed together power delivery and altmode parts
<hl>
i mean, I'm not saying XHCI should be made mandatory to USB Type-C... just that if you have XHCI in a system, it would be logical to use that as the configuration channel
<hl>
you'd add flags to XHCI so a port could be marked 'is Type-C', 'supports altmodes', 'supports PD', maybe also 'this port does not support USB', so it's there but can't be used normally. Add commands to TX/RX over PD serial comms, and commands to get a list of supported altmodes on the local side, and a command to set the altmode... now, any given XHCI controller would probably be designed by a vendor to, I
<hl>
dunno, process that command by setting GPIOs on the chip (just like the header), or I2C or something, and a XHCI add-in board maker could connect that to whatever altmode switching crap they have plumbed in
<whitequark>
so on current architecture
<whitequark>
the XHCI lives on the TBT controller IC and it isn't even powered until the USB PD controller wakes up the TBT controller
<hl>
I mean
<hl>
if you have a Type C add-in card, and you want to plumb it via ACPI, what's the host communications channel? PCIe or SMBus?
<whitequark>
like, that's not excusing them, that's explaining why
<whitequark>
neither
<whitequark>
existing TBT silicon can't do PM over PCIe, and existing PD silicon can't be exposed to SMBus
<hl>
right, exactly
<whitequark>
because you can probably blow the motherboard by fuzzing it
<hl>
I'm not talking about what is, just how Intel should have designed it if they weren't nucking futz
<whitequark>
given how much they failed at producing even *this* utter shit silicon...
<hl>
I can dream >_>
<whitequark>
if they went with a better design i don't know if they could have made it work at all
<whitequark>
like
<whitequark>
TI has a die respin of TPS65983 to add 20 kB of RAM to it
<hl>
But if USB-IF's adopting this, they're going to have to come up with _some_ solution that doesn't involve "??????? SMM ????? ACPI ??????? GPIO headers ?????"
<whitequark>
because they couldn't fit PD3
<sorear>
wondering how hl has avoided attention from minnich, leighton, et al
<hl>
avoided attention?
<hl>
whitequark: hahaha
<whitequark>
they are also doing everything to hide this fact, because i assume they are ashamed of it deeply
<whitequark>
some of their engineers spilled it on E2E forums
<hl>
yeah
<whitequark>
the TPS65983 is nearly identical to TPS65982
<whitequark>
they are firmware compatible in both directions, I tried
<whitequark>
but TPS65983 is TBT only
<whitequark>
and TBT requires TPS65983
<whitequark>
also
<whitequark>
TPS65983 docs are export controlled.
<whitequark>
they're not under NDA.
<whitequark>
but they ARE under export control.
<whitequark>
what the fuck??
<hl>
I have to wonder if Intel is actually suffering from skill loss (or at least an evacuation of all sane architects)
<whitequark>
skill loss?
<whitequark>
intel has always been like that
<hl>
yes.... TI seems very.... overenthusiastic about export control...
<hl>
True enough
<whitequark>
TPS65982 is *not* under export control.
<hl>
Can't help but feel they've been getting even worse, tho
<whitequark>
also, TI employees claim that Intel made them hide the USB PD docs.
<hl>
oh for
<whitequark>
and [redacted] laptop company employees claim that TI decided to hide the USB PD docs and pin this on Intel even though Intel doesn't care.
<hl>
as someone for whom non-public documentation is the absolute bane of my existence, fuck Intel
<sorear>
I have no love for UEFI/ACPI but trying to do anything without them means interacting with a small number of extremely insufferable people
<whitequark>
I mean that would be a genius move, just blame Intel for any inane shit you decide to do.
<whitequark>
"tire fire" doesn't even begin to describe that whole ecosystem
<hl>
I mean TI is an NDA-happy company too, though not nearly as bad as a lot of companies
<hl>
you know the beaglebone? Their Sitara processors have open datasheets and TRMs... great. Hilariously all the secure boot crap is in separate secret NDA'd documents. Because "security", I guess
<hl>
it's 2019 and the hardware industry still doesn't understand Kerckhoff's principle
<hl>
that whole industry is a fucking dumpster fire
<whitequark>
sorry, what
<whitequark>
BasicCard?
<whitequark>
what the everlivnig fuck?
<hl>
yes, yes
<hl>
this is an actual thing apparently
<hl>
suppppposedly some openpgp smartcards are implemented using it
<hl>
I have no idea what the fuck
<whitequark>
I'm going to start drinking again.
<hl>
I also find it randomly hilarious how mifare has for a long time been selling smartcards branded 'MIFARE DESFire' -- but they actually support 3DES, AES. Which tells you all you need to know about their customers - they're clueless enough that 'DES' isn't a customer-repellant
<sorear>
is "basiccard" what it says on the tin
<whitequark>
hl: >The microcontroller used in the Nitrokey Pro is an STM32F103TB. This microcontroller doesn't appear to offer as much in terms of fuse bits, etc. as the Atmel AT32UC3A3256S used for the Nitrokey Storage — see below — but apparently it is nonetheless possible to prevent readout via JTAG. So long as the device does not expose any facility to read out memory or change firmware via the USB
<whitequark>
interface, the device is secure.
<whitequark>
what you typically do is glitch the chip
<whitequark>
it's exceedingly unlikely that it is actually secure
<whitequark>
>The available information about the Nitrokey Pro then suggests a haphazard design in which some functions are performed on a microcontroller but others, for some reason, are performed by a smartcard chip. Perhaps this due to a lack of confidence in the security of the main microcontroller?
<whitequark>
oh yeah that's why
<whitequark>
with the rigth tools and know-how (which i lack) extracting data from the main uC is a weekedn job
<hl>
whitequark: yeah, I know... tbf I know more now than when I wrote that
<whitequark>
lol ECB
<sorear>
> SAM’s command system is a radical departure from prior spaceflight instrumentation. SAM is a BASIC interpreter. Its native command language encompasses the complete set of BASIC language constructs—FOR-NEXT, DO-WHILE, IF-ENDIF, GOTO and GOSUB—as well as a large set of unique built-in commands to perform all the specific functions necessary to configure and operate the instrument in all its possible modes.
<_whitenotifier>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±8] https://git.io/fhpjT
<_whitenotifier>
[whitequark/Glasgow] whitequark f55a512 - applet: use dedicated *Error for each *Interface class we have.
<marcan>
lol I think paste.debian.net is trying to talk to my yubikey
<whitequark>
er, that should be 9602
<whitequark>
actually, hm, let me look at BSDL
<marcan>
I get E: g.applet.program.xc9500xl: cannot select TAP #0
<marcan>
fwiw
<whitequark>
marcan: oh fuck's sake
<whitequark>
the 9536 actually has a *shorter ISDATA register*
<marcan>
ha
<whitequark>
this... violates basically every assumption my applet has
<marcan>
why does this sound so xilinx?
<whitequark>
xc95288 has an enormous ISDATA
<whitequark>
128 bit
<marcan>
lolol
<marcan>
so they scale up depth-first
<whitequark>
and95144 is 64 bit of course
<whitequark>
ughhhhhhhh
<whitequark>
i resent this deeply
<whitequark>
the address register is the same width
<whitequark>
what the fuck
<whitequark>
marcan: not depth-first.
<marcan>
T: g.applet.program.xc9500xl: JTAG-H: ir count does not match idcode count
<marcan>
E: g.applet.program.xc9500xl: cannot select TAP #0
<whitequark>
depth ONLY.
<marcan>
right
<marcan>
any idea what that TAP thing is about?
<whitequark>
yes.
<whitequark>
let me dig out my 9572xl board and i'll fix it.
<whitequark>
it's a consequence of some JTAG hardening i did recently
<whitequark>
intended although not entirely expected
<marcan>
I mean I'd like to understand this too so I wouldn't mind knowing what the problem is and trying to fix it myself :p
<marcan>
since ideally the goal here is for me not to have to ask you about everything eventually ;)
<whitequark>
sure
<whitequark>
give me a moment
<marcan>
kk
<whitequark>
so the IDCODE/BYPASS DR can be cleanly segmented if you know nothing about the chain
<whitequark>
but IR cannot be cleanly segmented because there's only one constraint, IR must start with 10
<whitequark>
therefore my code segments IR at every occurrence of 10
<marcan>
ah
<whitequark>
it used to do something , uh, well not this
<whitequark>
which happened to work right with just one TAP
<whitequark>
but it was buggy elsewhere
<whitequark>
what you should add is to special-case the single TAP case in select_tap
<whitequark>
because that's the only case where you never need to segment IR
<whitequark>
marcan: actually i guess i'll fix that
<whitequark>
but
<whitequark>
i really want you to fix the xc9500 code
<marcan>
sure
<whitequark>
because when i read my own documentation about xilinx internals again i want to vomit
<whitequark>
unsure how i even did it in the first place
<marcan>
I can make it work with the 36, but you'll have to validate that I don't break the 72 later
<whitequark>
sure
<whitequark>
let me solder to this board
<marcan>
is the bitfile format fixed?
<whitequark>
it has a stupid 1.27mm header
<whitequark>
not really
<whitequark>
it's just whatever
<marcan>
the .jed shit is xilinx proprietary, right?
<marcan>
not like svf
<whitequark>
jed is for JEDec
<marcan>
that's what I figured
<whitequark>
it is uh
<whitequark>
JED1 i think?
<whitequark>
no
<marcan>
it looked too sparse to be standard/generic stuff
<whitequark>
JESD3C
<whitequark>
bizarre, extremely old open standard
<whitequark>
the thing about jed files is they are a bitmap of every fuse in the device
<whitequark>
but they say nothing about how fuses are actually programmed
<marcan>
okay so it's .hex for PLDs
<marcan>
so basically useless
<whitequark>
correct
<whitequark>
glasgow doesn't even implement jed
<marcan>
I think we should implement a read-only thing to ingest xilinx jed files
<marcan>
but otherwise fuck them
<whitequark>
of course
<whitequark>
this needs a jed parser
<marcan>
well okay, so
<marcan>
1) make it read XC9536XL
<marcan>
2) make it write it and not brick it
<marcan>
3) make it read the JED file and prove it works
<whitequark>
yep
<marcan>
I'm going to stare at the xilinx applet, you can fix the TAP :P
<whitequark>
christ, what have i become?
<whitequark>
i just pulled a router out of a pile of 14 devices
<whitequark>
and that's just the useful ones
<whitequark>
i also have a pile of *useless* routers.
<marcan>
whitequark: do you prefer internal state or args for XC9500XLInterface? i.e. pass the device to every method or just have a set_device thing that sets state?
<marcan>
or even another class?
<whitequark>
neither
<whitequark>
pass it to the constructor
<marcan>
but identify()
<whitequark>
mmm
<whitequark>
let me see
<marcan>
could either set state after identify(), or have another class implement most of the interface and leave the generic class to basically just do identify()
<whitequark>
the latter is cleanest
<marcan>
k
<whitequark>
so you'd have a XC9500XLInterface (generic) and XC95xxXLInterface (specific)
<whitequark>
you'll also need to do something about arch.xc9500xl
<marcan>
oh I don't mean subclassing for each device
<whitequark>
yes
<marcan>
the device details can go in the device db
<whitequark>
the xx are in the name
<marcan>
oh sure
<whitequark>
you'll have to rework all the code that pokes registers
<marcan>
yes
<whitequark>
bizarrely, ISCONFIGURATION connects address AFTER data
<whitequark>
the Bitfield class is an awful hack inside
<whitequark>
it can't do anything over 64 bits
<whitequark>
certainly not 130 bits
<whitequark>
so, purge the DR_ bitfield definitions
<whitequark>
and i guess slice the bitarray directly or something
<whitequark>
nb: you always want the bitarray to be little endian
<whitequark>
otherwise, awful shit will silently happen
<whitequark>
i actually don't like that class a whole lot but a lot depends on it now, hrm
<marcan>
how does Bitfield manage to have a 64-bit limit?
<whitequark>
it uses ctypes unions and packed sturcts inside.
<whitequark>
yes. the literal worst way to implement Bitfield.
<whitequark>
i don't remember what the hell was i thinking
<marcan>
but. why.
<whitequark>
i have no idea.
<whitequark>
i'd say "i was drunk/high" but i definitely wasn't.
<marcan>
I like all the horrible metaprogramming in there
<marcan>
I'm learning about python features I didn't even know existed
<marcan>
:P
<whitequark>
lmao
<marcan>
I mean of course types.new_class is a thing
<marcan>
but I've never *had* to use that before
<whitequark>
look, i wasn't trying to be clever
<whitequark>
i was just really angry at something
<whitequark>
oh
<whitequark>
i made it for either XC9500XL or EJTAG
<whitequark>
that explains why it's so bad
<marcan>
lol
<whitequark>
it's because i was really pissed off at this piece of shit interface
<marcan>
okay I can accept frustration leading to bad code, but the moment you let ctypes creep in you have control issues :D
<marcan>
I'm debating whether I should try to understand and fix Bitfield
<whitequark>
i htink i didn't know about python's int.from_bytes back then
<marcan>
or just rewrite it from scratch
<whitequark>
or it would have been much easier
<whitequark>
you don't need to rewrite it from scratch, well not exactly
<whitequark>
just make it not use ctypes
<whitequark>
what you want is to have a canonical representation, bitfield._bits_
<whitequark>
which is a LE bitarray
<whitequark>
then implement from_* and to_* in terms of that
<marcan>
right
<whitequark>
then add accessors
<whitequark>
accessors can be added by doing like..
<marcan>
note that Bitfield() still takes a byte count and immediately multiplies by 8; once this is in I'll just push a commit to remove that and fix all callers
<_whitenotifier>
[whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fhhTY
<_whitenotifier>
[whitequark/Glasgow] marcan b209775 - revC1: fix ugliness in user LED schematic section
<marcan>
whitequark: mind if I squash the commit with all the callers? it's getting annoying to apply the fixes and keep that sane (since I added a bunch of tests that depend on exact widths)
<whitequark>
sure
<marcan>
actually splitting them makes no sense since we're now requiring complete definitions with no padding
<marcan>
whitequark: everything should be fixed, and I added a testcase for all the exceptions
<marcan>
(which caught a bunch of problems with those, lol)
<marcan>
(yay for tests)
<marcan>
er, actually pushing now
<_whitenotifier>
[whitequark/Glasgow] marcan pushed 1 commit to new-bitarray [+0/-0/±9] https://git.io/fhh32
<_whitenotifier>
[whitequark/Glasgow] marcan cb19a84 - support.bits: rewrite Bitfield around bitarray instead of ctypes
<_whitenotifier>
[Glasgow] marcan synchronize pull request #110: support.bits: rewrite Bitfield around bitarray instead of ctypes - https://git.io/fhhUX
<marcan>
whitequark: I desperately need sleep, but have a PR. Will push doc when I have write perms (or feel free to push yourself and fix the submodule commitref)
<marcan>
whitequark: fun fact: I totally bullshitted the endianness stuff, but upon first attempt at importing a jed file I realized (diffing against the usercode stuff I did have) I got it right by accident, so.
<marcan>
oh btw, unwinding: I haven't seen any failures yet on revC, blame the FXMAs?
<whitequark>
marcan: hrm
<whitequark>
github permissions strike again
<whitequark>
ok let me do something uhh
<whitequark>
I think I fixed it
<whitequark>
marcan: ^
<marcan>
ok
<_whitenotifier>
[GlasgowEmbedded/Glasgow-Archive] marcan pushed 1 commit to master [+1/-0/±0] https://git.io/fhhnr