<marcan>
< whitequark> and a special adapter that loops back the I/O bank pins <- so I was thinking about that
<marcan>
and I realized that with the pulls we can actually do interesting testing with nothing plugged in
<marcan>
using the pull ICs in input mode
<marcan>
the only untested part is a single trace from a via to the connector in that case, which is pretty unlikely to fail
<marcan>
not truly end to end, and we can't test e.g. high-speed performance, but it might be sufficient for some people
<whitequark>
marcan: hmmmmm
<marcan>
I want to extend the selftest to do a bunch of funky tests that way
<marcan>
also we can measure pin capacitance with the pulls
<whitequark>
yeah not bad
<marcan>
which I was thinking would require, for repeatability, either the FPGA mastering I²C to set the pulls, or the FPGA snooping on the pull I²C comms to be able to synchronize an internal timer with the exact cycle the pulls toggle
<marcan>
the latter is probably easier
<marcan>
(just means having a "shadow" listen-only I²C implementation)
<whitequark>
eugh
<marcan>
this sounds like a generally useful feature though
<marcan>
a module usable by applets that lets them trigger off of pull commands
<marcan>
we abstract out the comms and just deliver, well, basically pull value and OE
<marcan>
and the applet can use that as it sees fit
<marcan>
davidc__: do you have more info on those "cup" pogo pins?
<marcan>
I *may* be able to add testpoints for the IOs, but I'm not sure I want to, and obviously that wouldn't test the final solder joint, so those pogos sound better
<marcan>
won't work for the LVDS connector though, but shrug, that can just be untested/not mounted
<marcan>
whitequark: thoughts on that i2c thing?
<whitequark>
using pulls to selftest: good
<whitequark>
using pulls to measure capacitance by timing i2c: gross
<whitequark>
you don't need to touch pulls for that? you can do it with the fpga
<marcan>
whitequark: the pulls give you a nice 10K controlled impedance driving the pin
<marcan>
much better than driving hard from the shifter
<marcan>
it's not about timing i2c per se, the only purpose of interfacing i2c is to provide a trigger
<marcan>
like, you pull the pins low, then switch the pulls to high, then time how long until the pins go high
<marcan>
all you need is a signal synced to when the pulls toggle
<marcan>
to measure absolute time instead of having some uncertainty
<whitequark>
marcan: can't you enable pulls, drive them low, then release?
<marcan>
whitequark: true
<marcan>
I guess you could use the pulls to measure floating behavior more accurately though, if you can time when they drive :p
<marcan>
like float the pin for a while, then pull either way and time
<whitequark>
yes
<whitequark>
but
<whitequark>
hmm
<whitequark>
i just really don't want to make APIs for coordinating them, they feel fragile and finicky
<whitequark>
and the use case is marginal anyway
<whitequark>
i mean, i detect floating pins on revB
<whitequark>
in the jtag applet
<marcan>
fair
<whitequark>
marcan: btw i'm thinking about actually using the ATECC chip right now
<marcan>
heh
<whitequark>
marcan: so each device would have a priv/pub key pair. on startup i would ask the device to sign a nonce (to avoid replays), then give me its public key and a certificate
<whitequark>
a certificate is a counter (like a *real* serial number) that's hashed together with its public key and signed with the public key of the vendor's glasgow
<whitequark>
(the ATECC has a monotonic hardware counter that tops out at 2 million, which seems well enough)
<whitequark>
that's basically it
<marcan>
wait how is the internal ATECC counter related to this?
<marcan>
wouldn't the counter just be a manufacturer-side counter?
<whitequark>
yep
<marcan>
you mean using a glasgow unit as a counter? :p
<whitequark>
yep
<marcan>
lol
<marcan>
well that's an implementation detail
puck has quit [Quit: nya]
puck has joined #glasgow
<marcan>
what are you going to use for the certificate format?
<marcan>
you could roll your own binary fixed form thing, but that seems rather non-extensible
<marcan>
you could use x509 because lol that's what everyone uses
<whitequark>
do we need to extend it?
plaes has quit [Ping timeout: 245 seconds]
<whitequark>
all we need is to sign a public key and a serial
<whitequark>
and the ATECC can't even calculate the HMAC
<whitequark>
for external values that is
<marcan>
the only purpose of the ATECC is to hold a private key, no?
plaes has joined #glasgow
plaes has joined #glasgow
<whitequark>
yeah
<marcan>
so for the certificates, since this is largely a vendor thing, extensibility *could* be useful (e.g. a richer form of serial number etc)
<marcan>
which is a lot less puke-inducing than x509
<marcan>
the vendor implementation is largely arbitrary; sure you could use a glasgow as an "HSM", but that's a massive SPOF.
<whitequark>
mhm
<marcan>
*realistically* given the threat model involved I would just do it on a PC or something
<marcan>
and have, like, normal backups
<marcan>
but really vendors can figure out their own opsec
<whitequark>
i mean
<whitequark>
if the SPOF fails nothing bad has happened
<whitequark>
we just need to enroll another vendor key
<marcan>
sure, but that sucks :p
<marcan>
also having a single vendor key enrolled is desirable, but a single HSM does not scale
<marcan>
so then you need either certificate chains, or duplicating a key into several units (which means it leaves the ATECC anyway)
<whitequark>
i'm pretty sure we can have a keys.txt that's updated as needed
<marcan>
yes but that exposes an implementation detail to the public repo, e.g. how many glasgows a vendor is using for production
<marcan>
basically you want to not have to care about any of this
<whitequark>
hmmmm
<marcan>
you *could* implement single-level certificate chaining
<marcan>
that would give more than enough flexibility
<whitequark>
i could.
<marcan>
you keep the top-level key secure in whatever way you deem suitable
<marcan>
(a glasgow, a yubikey, a real HSM, and there are various backup schemes here)
<marcan>
and then delegate to keys which could e.g. be part of a glasgow inside a production rig (e.g. that would allow you to deploy it to a less-trusted production environment and still reasonably expect the key not to be stolen)
<whitequark>
so that'd be what... an intermediate pubkey, its signature, true serial, signature of everything before?
<marcan>
I'm not sure if you want to nest the signatures or not (most implementations I know of don't)
<whitequark>
i just mean you need to store all that on the atecc
<marcan>
how much memory does the atecc have?
<marcan>
I was kind of expecting to put the certs on spi
<marcan>
and just have the atecc be a crypto chip
m4ssi has joined #glasgow
<marcan>
the current serial is on spi anyway, right? might as well put the certs there too
<whitequark>
the atecc has 1208 bytes of memory
<whitequark>
we don't have spi
<whitequark>
we only have i2c eeproms
<whitequark>
and these tend to get corrupted if there's a write and power fails
<whitequark>
if we can stuff it all into the atecc we should just do that
<marcan>
er sorry, I meant i2c
<whitequark>
slot 8 is 416 bytes
<marcan>
so let's assume that for efficiency we're doing a binary encoding version of the JWS compact encoding
<whitequark>
large enough to store the certificate
<whitequark>
a signature is 64 bytes and a pubkey is 32 bytes, right
<marcan>
they're both 64 bytes
<marcan>
well, uncompressed
<whitequark>
oh, right
<marcan>
actually +1 apparently
<whitequark>
the datasheet says X and Y coordinates, 64 bytes total
<marcan>
so you can compress that
<whitequark>
mhm
<marcan>
but the problem is compression is patented lol
<whitequark>
i mean, 64 bytes root pubkey, 64 bytes intermediate pubkey, 64 bytes intermediate pubkey signature, 64 bytes serial number signature
<marcan>
oh apparently it expired, ha
<marcan>
yes, that's where my 256 earlier came from
<whitequark>
so exactly 256 bytes is sufficient
<whitequark>
right
<marcan>
but apparently you can get away with 33 byte pubkeys
<marcan>
you also need names though
<whitequark>
do i?
<marcan>
you need to identify which root key is used
<marcan>
and you want to be able to at least have a vague idea of what you're dealing with if it's not in the database
<whitequark>
mmmm
<marcan>
it's also helpful to give the intermediate key a name
<marcan>
and you need the serial
<marcan>
so 256 bytes plus 3 pascal strings
<whitequark>
the serial is inside the device
<whitequark>
like the atecc chip
<marcan>
so if the i2c gets fucked you get to bruteforce the serial matching the atecc data? come on
<marcan>
you told me the whole point of putting this in the atecc is to not lose it
<marcan>
:p
<whitequark>
no the atecc already has an unique 72 bit serial
<marcan>
oh you're signing *that*?
<whitequark>
yes, it's completely separate from the serial you see in the UI
<whitequark>
which could be any random string really
<marcan>
ehh but you want to be able to tie those
<marcan>
without having a database
<whitequark>
i was thinking about leaving that user-programmable
<marcan>
I mean the easy way to do this is to just sign the user visible serial too
<marcan>
and throw it in the atecc
<marcan>
anyway if you don't mind using EC point compression, the baseline is 194 bytes
<marcan>
and really 100 bytes should be enough for all those strings combined
<marcan>
it'll fit
<whitequark>
mhm
<marcan>
it just won't be extensible
<marcan>
:p
<whitequark>
marcan: so the problem with signing user-visible serials is they aren't unique
<whitequark>
it's just a timestamp
<marcan>
you can sign both that *and* the atecc serial
<marcan>
also they should be unique
<marcan>
honestly I think standardizing on a timestamp is limiting, let people make serials however they want.
<marcan>
like having a timestamp is *fine* but it shouldn't be the *only* thing there
<whitequark>
i actually quite like the idea of it being a *user* programmable serial
<whitequark>
like if you want your glasgow to be called C1-LAB10-DESK5, why the hell not
<marcan>
okay, so then the ATECC should hold a "factory" serial that is == the serial as it was sold
<whitequark>
what's the point of that?
<marcan>
that that's what the label will have
<whitequark>
like the ATECC isn't enforcing correct serials or anything
<whitequark>
the only thing it does is replacing trademarks
<marcan>
it's useful to know *what* unit you have, not just that you have *a* unit from a given vendor
<whitequark>
mhm
<whitequark>
so you're basically suggesting signing a timestamp, right?
<marcan>
and you should have some way of making that process unique
<marcan>
I mean it's *entirely* reasonable to have two lines making glasgows under the same vendor
<marcan>
and *entirely* reasonable for them to collide on the same second
<marcan>
and *entirely* unacceptable for that to cause colliding USB serials
<marcan>
so you have a problem you need to fix there
<whitequark>
why is it entirely unacceptable?
<whitequark>
just reprogram one of them
<marcan>
because it violates the USB spec, for one
<whitequark>
yeah but i'm not gonna make them longer
<marcan>
and how do you distinguish those units then?
<marcan>
at sales time
<marcan>
this makes no sense
<marcan>
what's the point of the timestamp then
<marcan>
a manufacturing timestamp is a terrible serial
<marcan>
part of a timestamp might make for a reasoanble part of a serial
<marcan>
having just a timestamp *be* the serial is dumb, sorry
<marcan>
those are different things
<marcan>
maybe just ditch the whole timestamp idea and let manufacturers use whatever scheme they want within the current length?
<marcan>
I mean this timestamp thing is cute for people making glasgows in small volumes, but it doesn't scale, and if we're thinking about "serious" manufacturing it doesn't really work any more
<whitequark>
okay then let's do this
<whitequark>
the first 8 bytes of the ATECC serial in hex are the serial, if there is an ATECC chip
<whitequark>
if someone doesn't want an ATECC chip then it falls back to a random 8 bytes
<whitequark>
(the ATECC serial is 9 bytes for some reason)
<marcan>
you need an extra bit there to distinguish those two cases
<marcan>
do we know what the atecc serial format is? are there any fixed bytes?
<marcan>
I don't like the idea of blindly dropping a byte
<whitequark>
the ATECC serial always starts with 0x01 0x23 and ends with 0xEE
<whitequark>
so we could have serials starting with ECC and then 48 hex bits
<whitequark>
and RNG and then 48 hex bits
<whitequark>
or something
<marcan>
ECA and RNA or something, so if we change to another chip or those fixed bytes stop being fixed in the same way we can go to ECB etc
<whitequark>
sure
<marcan>
sounds good
<marcan>
and you could make user serials just start with U by convention
<marcan>
like UC1-LAB10-DESK5 or whatever
<whitequark>
UC1?
<marcan>
17:50:49 < whitequark> like if you want your glasgow to be called C1-LAB10-DESK5, why the hell not
<marcan>
er sorry
<marcan>
C1 is the rev, right
<whitequark>
oh the C1 part is the glasgow revision
<whitequark>
it's stored separately
<whitequark>
as a byte 0xC1
<marcan>
C1-ULAB10 or whatever
<whitequark>
yeah
<whitequark>
sure
<whitequark>
the manufacturing key should be password-protected, right
<marcan>
I suggest putting that 0xc1 in the cert and signing it too. can't hurt, might disambiguate some special cases
<marcan>
(like patching up c0 into c1)
<whitequark>
sure
<tnt>
Just picking this up in the middle, but what's the goal of all of this btw ?
<marcan>
whitequark: btw the sample vendor name for any docs/code related to this should be "Fabulous Testing Doodads Inc"
<marcan>
whitequark: let me run this scheme through bunnie before we commit, btw
<whitequark>
sure
Hellsenberg has joined #glasgow
q3k has joined #glasgow
eddyb has joined #glasgow
<eddyb>
oops I think I joined this in january when it wasn't registered yet and forgot about it eventually existing
<eddyb>
#timetravelproblems
<sorear>
oops
ar has joined #glasgow
pie__ has joined #glasgow
Javantea has quit [Ping timeout: 245 seconds]
Javantea has joined #glasgow
scott has joined #glasgow
ali_as has joined #glasgow
uovo is now known as egg|floating|egg
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt>
"block protect bits are set to 0100, program/erase command might not succeed"
<tnt>
is there an obvious command I'm missing to unprotect ?
<tnt>
Damnit, I've been looking for 15 min why I was getting random corruption when talking to that flash chip .... until I realized I forgot to connect the GND between the DUT and glasgow ... doh !
ali_as has quit [Remote host closed the connection]
<davidc__>
so if you make other signals accessible, (and if the connector pitch is reasonable), you can probe everything from one side of the board
<marcan>
davidc__: any preference for top side vs botom side? LVDS is only on the top side of course
<davidc__>
marcan: more of a question for whoever will be fabbing the board
<davidc__>
Also worth determining if that LVDS connector pitch is too tight for pogos
<marcan>
it's 1.27mm, not sure if they make pogos that work with that
<marcan>
I figure they probably do?
<davidc__>
possibly. Not sure about the "cup" style ones. I know you can get "point" probes in that pitch
<davidc__>
Also, re "LED" test, depends whether you want automated testing for the LEDs or human
<davidc__>
probably at glasgow volumes, human will be fine (which means board must face up, which means probes from backside
<marcan>
hmm
<marcan>
I don't think LVDS is going to fly then though
<marcan>
putting pads for that whole thing on the back is... impractical
<davidc__>
marcan: why? drop a via on the trace and center the test pad on the via
<marcan>
the traces are already on both sides of the board
<davidc__>
stub length of a single via is probably not a big deal at the frequencies that FPGA can drive
<marcan>
have a good idea for a reasonable testpoint diameter?
<marcan>
right now we use 1mm
<marcan>
but that's a bit tight
<davidc__>
tight as in "hard to pack", or "hard to hit"?
<marcan>
hard to pack
<davidc__>
doesn't have to be in a linear row under the connector
<davidc__>
just drop em wherever convenient
<davidc__>
(but that might offend certain sensibilities ;)
<marcan>
*cough*
m4ssi has quit [Remote host closed the connection]
<davidc__>
well, you can always get fancy and test everything from the front (including fancy optics to check each LED - but that part violates KISS in a rather major way)
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±4] https://git.io/fjtdp
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan e91c7a9 - revC1: add USB testpoints to the rear
<davidc__>
What matters is "is this a feature we're advertising as functioning" and "is the probability of failure of the fab process >> than our acceptable failure rate"
<davidc__>
Also, what is your match target :P
edef has joined #glasgow
<marcan>
davidc__: something like +/-.5mm
<davidc__>
marcan: have you calculated that or just decided on that? :P
<marcan>
it's whatever kicad defaulted to? :p
<marcan>
this all *started* as "hey kicad has a length matching tool, let's just use it because why not"
<davidc__>
marcan: because if my memory of the rule of thumb is correct, you're more than an order of magnitude above what actually matters :P
<davidc__>
(at the frequencies that the iCE40 could plausibly hit)
<davidc__>
though, I'd want to actually check that with math
m4ssi has joined #glasgow
<tnt>
davidc__: if you use DDR IO and immediately 'deserialize' to N:1, the ice40 can go reasonably high frequency.
<tnt>
I have logic running fine at 300 mbits.
<tnt>
(and that's a up5k so the hx one is the high perf one)
<marcan>
davidc__: or just have a connector that is manually plugged in, for those who want to manufacture this with it populated
<marcan>
(could be as simple as looping back all the pins in a pattern that cannot be caused by adjacent pins being shorted in any location)
<davidc__>
marcan: yes. (as I mentioned above, perfectly acceptable to use a cable, as long as one recognizes that a) a human needs to do it, and b) the cable is a consumable, though for IDC pin headers, the cable usually can't harm the header)
pie___ has joined #glasgow
pie__ has quit [Remote host closed the connection]
<_whitenotifier-1>
[Glasgow] whitequark closed issue #122: USB test points - https://git.io/fjtaf
<_whitenotifier-1>
[Glasgow] whitequark commented on issue #122: USB test points - https://git.io/fjtxn
m4ssi has quit [Remote host closed the connection]