<sorear>
revB: dim LEDs; added USB current limiter; level shifter series resistors // revC0: no more autosensing; LVDS and AUX ports; HX8K; serial#; user LEDs // revC1: dim LEDs; power filters; different voltage regulators; ESD diodes; SYNC 5V tolerance; pulls no longer use an I2C level shifter; Vio LEDs and discharge resistor
<sorear>
the one thing that is different between every pair of board revs is the SYNC series resistor :)
<sorear>
revA is more recognizable than I expected
<sorear>
only just realized that the ESD diodes are all zeners
gsuberland has quit [Ping timeout: 245 seconds]
scott has quit [Ping timeout: 258 seconds]
scott has joined #glasgow
<marcan>
sorear: they aren't zeners, they're TVS diodes
<marcan>
which are similar (and use the same symbol) but not the same
jn___ has joined #glasgow
jn__ has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined #glasgow
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined #glasgow
modrobert has quit [Ping timeout: 245 seconds]
modrobert has joined #glasgow
_whitelogger has joined #glasgow
mehar_ has joined #glasgow
mehar has quit [Ping timeout: 258 seconds]
m4ssi has joined #glasgow
<whitequark>
serial# was there on revAB
_whitelogger has joined #glasgow
jn___ is now known as jn__
_whitelogger has joined #glasgow
emily has quit [Remote host closed the connection]
emily has joined #glasgow
<electronic_eel>
whitequark: re pic programming - a lot of the prog algos require higher voltage on at least one pin to enter programming mode
<whitequark>
um, yes, i've read some of those docs
<electronic_eel>
so you'd need some high voltage addon for Glasgow
<electronic_eel>
unfortunately the author chose to code all that in c...
<whitequark>
it's not a huge problem to reimplement programming algorithms ime
<electronic_eel>
yes, not that difficult.
<electronic_eel>
If we create a hv addon it would make sense to just have one and cover most applications with it
<electronic_eel>
old eproms, pals, gals and the like often also need hv
<whitequark>
true...
<whitequark>
needs some kind of muxing though, maybe just a huge pfet array?
futarisIRCcloud has joined #glasgow
<whitequark>
also the problem with old eproms, pals and gals is that they're all horribly parallel
<electronic_eel>
perfect for a fpga
<whitequark>
not perfect for our 16 pins
<electronic_eel>
fair point
<electronic_eel>
and we don't have 16 pins
<whitequark>
and no FPGA can drive 5V pins on those devices anwyay
<electronic_eel>
since we don't have a dedicated addon interface
<electronic_eel>
we need something to control the addon
<whitequark>
i'm thinking it should use a set of fast shift registers
<electronic_eel>
ok, that could work
<electronic_eel>
I haven't worked with these on a programming interface level
<whitequark>
it's really annoying
<electronic_eel>
what are the voltages on the data pins?
<whitequark>
you can easily have 20 address bits
<whitequark>
and they're all in random locations interspersed with strobes
<whitequark>
usually 5V
<whitequark>
there are some parallel 3V3 devices
<electronic_eel>
so the high voltages and negative voltages and so on are only on special pins
<whitequark>
yes
<electronic_eel>
how should the addon work physically?
<whitequark>
no idea
<whitequark>
it's a really hard problem
<electronic_eel>
pin headers and wires? or a zif socket
<whitequark>
for something like a PIC it would be pin headers and wires since you want ICSP
<electronic_eel>
zif socket means you need something to cater for different pinouts
<whitequark>
well in circuit
<electronic_eel>
hv in circuit?
<whitequark>
sure
<whitequark>
just don't connect MCLR to anything else
<electronic_eel>
am I happy that I don't have to support something like that on the boards I design now...
<electronic_eel>
maybe we should leave out eproms, pals and gals for the beginning
<electronic_eel>
then we just need hv on dedicated pins and the user can connect these to his circuit
<whitequark>
yep
<electronic_eel>
whitequark: are you eager to do pic soon?
<electronic_eel>
wouldn't it be better to start with the stuff that doesn't require addons?
<whitequark>
well i wanted to do it like right now
<whitequark>
pic has low voltage programming
<whitequark>
on.. many? most? chips
<electronic_eel>
I hate pics.
<electronic_eel>
I thought you need hv on a lot of them
<whitequark>
i utterly resent pics
<electronic_eel>
I though just the newer series work without
<whitequark>
shit architecture
<electronic_eel>
then why not finish the avr stuff first (except hv of course)?
<whitequark>
finish?
<electronic_eel>
or do you have a bad day and want to complement it with a arch you resent?
<electronic_eel>
I mean the rest of the avr protocols
<electronic_eel>
updi, pdi,...
<whitequark>
i have no intention of sitting down and implementing each avr protocol in series
<electronic_eel>
ok
<whitequark>
the avr spi protocol is done
<whitequark>
but it needs a full database
<electronic_eel>
can't you re-use the model table with the ids and so on from avrdude?
<whitequark>
avrdude is GPLv2
<electronic_eel>
ok, so you can't copy the table straight into glasgow
<whitequark>
yes, it could be processed
<electronic_eel>
but you could write a converter
<electronic_eel>
it's not just about recreating the table once
<electronic_eel>
it's also about maintaining it
<electronic_eel>
there are new models released every few months, avrdude usually has them in their table after some short time
<electronic_eel>
would be nice to not having to replicate this work again and again
<whitequark>
i'm not really a fan of their database format
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<electronic_eel>
maybe a converter + a patch to fix the known shortcomings?
<whitequark>
it's the design
<electronic_eel>
I understand
<electronic_eel>
but do you really want to re-do all this work and maintain it over the years?
<whitequark>
if i can't do it well i would rather not have it at all
<electronic_eel>
I fully understand you
<whitequark>
for example it is not really possible to use HVSP data from avrdude
<whitequark>
since it is stk500-only
<electronic_eel>
I'm lazy. And recreating this looks like tedious and work and not fun.
<electronic_eel>
So I'd perfer to put lot's of effort into designing a nice importer/converter/whatever and a matching format
<whitequark>
you can't do a nice importer for a format that's broken by design
<whitequark>
what *is* possible is to parse their tables and *categorize* the microcontrollers according to the actual algorithm used
<whitequark>
that would be very useful indeed
<electronic_eel>
reading out the memory sections and their addresses & sizes should also be possible
<whitequark>
sure
<whitequark>
but i don't want each device to set up its own algorithm for reading out signature bytes
<whitequark>
when chances are it's the same for every one of them
<electronic_eel>
you mean you don't want the user to select a model on the commandline?
<whitequark>
no, i mean i don't want a 14000 line database in glasgow for no other reason than someone being lazy
<electronic_eel>
so you want to group the devices more intelligently than one big table
<whitequark>
yup
<whitequark>
and btw i just checked
<whitequark>
the command for reading the signature is always identical but they have 3 or 4 ways to specify it in the database
<electronic_eel>
but wouldn't some categorization script be possible to do that?
<whitequark>
differing in indentation, spacing, and don't care bits
<electronic_eel>
I mean from the avrdude table
<whitequark>
sure
<whitequark>
13:05 <@whitequark> what *is* possible is to parse their tables and *categorize* the microcontrollers according to the actual algorithm used
<whitequark>
that's what i was talking about
<whitequark>
if you wrote that it'd be excellent
<whitequark>
and yes, i don't think specifying the part number on the command line should be necessary
<electronic_eel>
hmm. I'd prefer to work on the voltage protection board first
<electronic_eel>
and there are also some projects of my own battling for my attention
<whitequark>
sure
<whitequark>
it's not like there's any rush
<electronic_eel>
I'm still not sure if it isn't a better route to somehow integrate with avrdude than rewriting it
<electronic_eel>
it isn't as elegant
<electronic_eel>
or fast
<electronic_eel>
but it would allow to use the development time to be used for implementing more interfaces to other stuff
<electronic_eel>
but on the other hand all development is voluntary
<whitequark>
i feel like maintaining the *avrdude* database is a huge waste of time
<whitequark>
almost every single chip there has its own complete protocol definition
<whitequark>
they seem to have caught on with xmega
<electronic_eel>
I think their idea was to make it as flat as possible
<electronic_eel>
and put as many stuff in their as possible
<whitequark>
it's one of those things where months of maintenance save hours of planning
<electronic_eel>
so that a user could add a new chip without having to change the code
<whitequark>
it's not entirely bad
<whitequark>
but it's seriously lacking in planning
<electronic_eel>
probably it slowly grew over the years
<whitequark>
yes
<whitequark>
i understand well how these things happen
<whitequark>
that's why i refuse to repeat them
<electronic_eel>
without any review breaks and re-evaluation in between
emily has quit [Quit: Updating details, brb]
emily has joined #glasgow
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+2/-2/±1] https://git.io/fjnLn
<whitequark>
electronic_eel: also thinking out loud re: chip support
<whitequark>
devices like BMP are still quite successful even if they don't support the entire lineup of one developer's ICs
<electronic_eel>
yes
<electronic_eel>
but takes quite a lot of maintenance to add & test all the new ics
<electronic_eel>
bmp doesn't have many developers
<whitequark>
sure
<electronic_eel>
and it shows, there is quite a backlog of patches
<electronic_eel>
openocd has quite a wide range of supported interfaces
<electronic_eel>
so i guess their internal interface isn't that bad
<whitequark>
a backlog of patches isn't necessarily representative
<whitequark>
most patches made by people for tools are quite bad, because most people are, thankfully, not toolmakers
<whitequark>
e.g. solvespace suffers from it badly
<electronic_eel>
fair point
<whitequark>
i somewhat dread general availability of glasgow because such patches are my worst nightmare
<whitequark>
i expect to spend a lot of time writing guidelines and best practices
<electronic_eel>
but still there is some influx of patches and if the project wants to appeal to a wide audience, it has to deal somehow with it
<whitequark>
for example, compare the situation to yosys
<whitequark>
yosys has quite a few people behind it that are very active
<whitequark>
yet there is a backlog of PRs that are incomplete, not up to standard or just kind of incoherent
<electronic_eel>
and i don't know if it is best to use these developer resources with handling this id of that new ic
<whitequark>
adding this id of that new ic is not hard at all.
<electronic_eel>
if we get an interface into openocd to work, most of this is handled by openocd
<whitequark>
well, it should not be hard.
<electronic_eel>
and everyone else using openocd will also profit from it
<whitequark>
except now all the programming algorithms are trapped in gplv2-land
<whitequark>
and databases
<sorear>
seems like the exciting stuff is the part where we don't collectively know yet if it's in scope
<electronic_eel>
don't underestimate it, it's not just the ids, but some individual quirks needed
<whitequark>
i am well aware
<whitequark>
i implemented mips ejtag support, for example
<electronic_eel>
is gplv2 that bad?
<whitequark>
i'm opposed to all intellectual property
<whitequark>
and gpl can't exist without it
<whitequark>
so yes
<whitequark>
that's enough reason for me to reimplement algorithms
<electronic_eel>
if there were no ip, gpl wouldn't have to be invented
<whitequark>
gpl was invented because one guy got really pissed off
<whitequark>
everything else is mostly coincidental
nrossi has quit [*.net *.split]
StM has quit [*.net *.split]
<electronic_eel>
i mostly care if the stuff is open source or not
<electronic_eel>
true open source, not some shit like agpl
<whitequark>
well, i consider anything short of public domain "not true open source"
<electronic_eel>
if it is that is good enough for me
<whitequark>
to make an analogy
<whitequark>
of course, i still use, contribute to, and maintain gpl'd projects. i also run nvidia's blob
<whitequark>
that doesn't mean i will willingly make things worse when i have a good option not to
<electronic_eel>
i just run intel me and hate that i have to do it
<whitequark>
intel me is shit but like
<whitequark>
linux already falls over if anyone fuzzes it for five miuntes
<electronic_eel>
on which interface?
<whitequark>
we have a long way before intel me becomes a more accessible target than all the other junk i run on this system
<electronic_eel>
usb drivers?
<whitequark>
anything that parses untrusted input in c tends to fall over regularly
<whitequark>
i mean linux broadly
<whitequark>
as in "this debian desktop"
<electronic_eel>
ok, so not the kernel, but whole desktop. yeah
<sorear>
i will never understand the philosophy that believes an infinite amount of IP is fine, as long as it's not software you have to handle
<whitequark>
i'm completely certain the wifi firmware is remotely exploitable and i also know for sure the current gen iommu linux drivers wouldn't prevent anything
Stary has quit [*.net *.split]
<sorear>
secret sauce in silicon? great. microcode in ROM? great. microcode updates in /lib/firmware? Suddenly I Mind
<electronic_eel>
iommu is not worth much unfortunately
<whitequark>
sorear: i mean, FSF is *also* incoherent but that's kind of a given
<electronic_eel>
that is why i think this whole thunderbolt thing is immature
<whitequark>
electronic_eel: i think thunderbolt is excellent
<whitequark>
well, other than the 98% of it that is shit
<whitequark>
but when it works and if i pretend i don't know how it works, it's excellent
<electronic_eel>
giving remote dma to some external device?
<whitequark>
yes
<whitequark>
i specifically want that
<electronic_eel>
but then iommu has to be really really really good
<electronic_eel>
and it isn't
<whitequark>
there's no meaningful protection from malicious devices in today's desktop architecture
<whitequark>
consider this
<whitequark>
a far easier and more reliable way to do a malicious device thing is to make a HID thing that installs a keylogger on your machine
<whitequark>
or just exploit autorun bugs in systemd or whatever
<electronic_eel>
not when my machine is locked, that is what i mostly care about
<whitequark>
wait
<whitequark>
do you think thunderbolt blindly grands dma to anything that's plugged in?
<electronic_eel>
if some driver is loaded i guess
<whitequark>
nope
<whitequark>
i mean, you could set it up like that if you wanted, but by default it's a device whitelist and a challenge-response auth mechanism
<whitequark>
(so it's even replay-safe, in theory at least; i don't know if it's horribly broken in reality)
<electronic_eel>
do you need to ack plugging in any device?
<whitequark>
by default, yes
<electronic_eel>
only the first time or always?
<whitequark>
however your OS does it
<whitequark>
there's three modes
<whitequark>
"instantly set up anything that's plugged in", "ask the user", "ask the user first time and pair devices"
<whitequark>
the OS can select between those and you can also configure it in the firmware
<electronic_eel>
how good is the pairing stuff done?
<whitequark>
because if the former one is selected the firmware will enumerate whatever's on the other side of the bus and *run option ROMs off it*
<whitequark>
none of the thunderbolt guts are public currently
<whitequark>
(i'm also not a cryptographer)
<whitequark>
i only know it uses some kind of crypto and challenge response auth
<electronic_eel>
ok, so then there is probably a lot of holes in it
<electronic_eel>
like plugging in a man-in-the-middle between your paired device and the pc
<whitequark>
good luck making that work
<electronic_eel>
most crypto stuff that is developed behind closed doors is leaky as a sieve
<whitequark>
no i just mean implementing thunderbolt is a nightmare
<electronic_eel>
currently, because its all closed intel chipsets
<electronic_eel>
but once it becomes usb 4 and open
<whitequark>
here's the thing
<electronic_eel>
wait a few years and you get all kinds of interfaces
<whitequark>
you can fuzz usb drivers in linux right now and
<whitequark>
i mean
<whitequark>
if you're developing an usb device it's harder to *not* crash the host stack sometimes
<whitequark>
and it's not like that's gonna change
<whitequark>
what we need is to stop treating correctness like an afterthought and once you have that, getting iommu to work properly is straightforward
<whitequark>
because you're already not putting pointers into device-writable memory
<electronic_eel>
i better go back to the board i was soldering, won't get anywhere with it today otherwise
<whitequark>
oh btw
<whitequark>
i've never heard anyone complain like this about expresscard
<whitequark>
even though it was far easier to exploit
<electronic_eel>
was a non-starter, nobody needed it
<whitequark>
oh?
<electronic_eel>
so you could easily epoxy it closed
<whitequark>
that's a nonsequitur
<electronic_eel>
can't do that with usb
<whitequark>
you can just turn off thunderbolt
<electronic_eel>
not if there are lots of devices that need it
<electronic_eel>
or are designed with the premise that you can use it
<whitequark>
so what does thunderbolt make worse over usb exactly
<electronic_eel>
once you get around the iommu, which isn't that hard today, you have the whole ram
<electronic_eel>
with usb you need to find a vulnerable driver and write an exploit
<whitequark>
so
<whitequark>
what's the problem with never enumerating new thunderbolt devices when the screen is locked
<electronic_eel>
and the driver is easily fixed, iommu hardware is only fixed in >3 years in next gen
<whitequark>
since if the screen is unlocked the solution is to use a fake HID
<whitequark>
actually fake Ethernet still gives you a lot even with a locked screen
carl0s has joined #glasgow
<electronic_eel>
yeah, a lot of distros do auto dhcp
<electronic_eel>
that is really bad practice
<whitequark>
also, if you use most x11 screen lockers they are bypassable with user input
<whitequark>
so it's more like step 0: move to wayland
<electronic_eel>
bypassable?
<whitequark>
yes
<whitequark>
x11 doesn't have the concept of a screen locker
nrossi has joined #glasgow
<whitequark>
so it's a program that just tries to grab the display really hard, usually using some complex toolkit
<whitequark>
this pretty much always fails in some stupid way
<whitequark>
e.g. i remember a bug where you could type a password, ctrlc, ctrlv, repeat several times
<whitequark>
it crashed with OOM
<whitequark>
screen lock gone
JJJollyjim has joined #glasgow
JJJollyjim has joined #glasgow
JJJollyjim has quit [Ping timeout: 250 seconds]
<whitequark>
often you have some things like assistive technologies interfering with focus grabs
<whitequark>
or menus
StM has joined #glasgow
<whitequark>
or some keybinding someone forgot to sanitize
Stary has joined #glasgow
<electronic_eel>
just killed my screen locker
<electronic_eel>
it was automatically restarted and re-locked
<electronic_eel>
kscreenlocker
JJJollyjim is now known as Guest96158
<whitequark>
do that but get a popup menu while it's crashed
<whitequark>
there has been a race condition in the past
<whitequark>
since only one application can do focus grab at a time
<whitequark>
what i'm saying is, yes they fix those bugs, no the x11 screen locking is broken by design
<whitequark>
it's like writing kernels in c
<whitequark>
don't do it
<electronic_eel>
yes, i understand
<sorear>
does wayland let you switch vts or use magic sysrq while locked
<electronic_eel>
but wayland is just missing lot's of stuff users are accustomed to
<whitequark>
magic sysrq is disabled on default on many distros these days
<whitequark>
which is fucking obnoxious
<electronic_eel>
won't take the world by storm this way
<whitequark>
your piece of shit kernel can't deal with OOM, i *need* alt+sysrq+k
<whitequark>
as for switch vts, i thought that's a kernel thing?
<sorear>
you must mean something I'm not quite understanding because they're both kernel things as I use the term
<sorear>
the kernel reacts to at least two classes of user input (VT switch sequences, magic sysrq) before userspace sees them
<whitequark>
yes
<whitequark>
magic sysrq is disabled by default though
<whitequark>
it might've been an upstream change?
<sorear>
there's a sysctl to disable sysrq at runtime, and an ioctl for intercepting VT switching*, so theoretically wayland could make this work, but it's not "correct by design" and it'll break the next time linux adds a new magic key
<sorear>
*this part of my knowledge hasn't really been updated to reflect drm/kms, it's _really_ dated
<sorear>
xfree86 circa 2003 was cursed as hell
<sorear>
I'd like to be able to use magic sysrq while logged in, but have it do nothing while locked, do you follow my desire?
<whitequark>
sorear: i mean, "kernel adding new magic keys" is outside the threat model of a display manager
<whitequark>
if you want things like disabling usb/thunderbolt enumeration the kernel has to explicitly cooperate
<whitequark>
this rules out scenarios where the kernel is oblivious or malicious