<tnt>
I'm wondering what would be the best way (if at all possible), to have Glasgow register itself as a spi/i2c/gpio provider to the kernel (so I can for instance, load a driver for a touch controller and use it as input device while it's connected to glasgow, or things like that).
<whitequark>
tnt: needs an userspace gateway, IMO
<whitequark>
like FUSE but for SPI/I2C/...
<whitequark>
it's certainly possible to poke Glasgow directly from the kernel but that way lies madness, with driver conflicts and such
<eddyb>
hmm FUSE is sort of "microkernel services but only for the VFS interface" isn't it? linux could benefit from more microkernel-like infrastructure
<eddyb>
tnt: for touch specifically, I think X and libinput both support userspace input drivers, you could maybe look into that?
<whitequark>
that doesn't help you if you want to debug an in-kernel driver for an SPI device
<tnt>
eddyb: I don't want to re-implement the touch drivers ...
<whitequark>
or reuse
<tnt>
also that was just an example.
<whitequark>
tnt: yeah I'd be super interested in a "FUSE for SPI"
<eddyb>
oh sorry, right, this isn't a custom device necessarily
<whitequark>
it would ideally go into contrib/ under the glasgow repo
<whitequark>
and upstream if someone wants to bother
<eddyb>
oh hey this could be a bridge to reimplementing device drivers in a less OS-specific fashion - like CDI/UDI but, well, better-designed (more like Fuchsia, but even that is not declarative enough IMO - and they do have some hacks in the kernel for device drivers)
<eddyb>
(I was going to say "in Rust" initially but that's less important than "not C running in ring 0")
<electronic_eel>
at least for i2c there are is i2c-tiny-usb in the kernel
<electronic_eel>
one could probably implement the device-side of it in the fx2
<whitequark>
no, i would really want to avoid that.
<whitequark>
we have 4 kB free on the FX2
<whitequark>
anything else that goes in it, has to pull its weight.
<whitequark>
sdcc doesn't do any IPO and i use lots of small functions, so it could probably be optimized, at the cost of turning it into spaghetti
<whitequark>
full of macros probably
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjmrg
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Stary has joined #glasgow
merry has joined #glasgow
JTL has joined #glasgow
<thaytan>
whitequark, I just want to say - reading your twitter feed is fucking terrific. I'm so glad I stumbled across it
<thaytan>
and I'm looking forward to Glasgow GA :)
<whitequark>
:D
<eddyb>
same, I think that if tiby ends up building any kind of 3+ axis machine, it's likely going to be driven by a Glasgow :D
<eddyb>
oh and I'm much more comfortable probing problematic boards with a Glasgow than some random uC's I2C support or w/e (although for some things we might have to invest in a scope too)
<whitequark>
oh i have a WIP branch with stepper motor support
<eddyb>
<3
<whitequark>
and yes, probing random boards is what glasgow is designed for
<eddyb>
I've accumulated 2 laptops for which the screen doesn't turn on anymore and idk how broken they are, and a PS4 with a fried DP->HDMI converter chip (but the rest seems to boot as usual)
<eddyb>
oh and some old PII or PIII (I can never remember right) PC, that's a fun one :P
<eddyb>
whitequark: how versatile is the floppy driving stuff, btw? in terms of code that would be shared with an emulator? I think it could be neat to use Glasgow for providing the floppy contents via USB, to some retro machine, although PATA might be easier overall
<whitequark>
there are existing devices that do this
<whitequark>
glasgow would probably need additional memory, though you MIGHT be able to stream data just in time
<eddyb>
right, sorry, you wouldn't need to bother for standard floppies
<whitequark>
key word is might
<eddyb>
(unless you wanted to, or had a defective host or some other unusual situation like that)
<whitequark>
i mean, replacig floppy drives makes a lot of sense
<whitequark>
good floppies are rare and they write slowly as heck
<eddyb>
(my logic is floppies seem incredibly fragile and switching between them is unnecessary manual labor)
<eddyb>
whitequark: I mean, you wouldn't need to bother if you could use an off-the-shelf device, like you said
<eddyb>
but I'd still bypass actual floppies either way
<whitequark>
glasgow is potentially better than an off-the-shelf device
<eddyb>
<3
<whitequark>
like you could make it an infinite floppy
<eddyb>
omfg
<whitequark>
i mean technically there's nothing preventing you from having infinite tracks
<whitequark>
every OS would break
<eddyb>
I had that thought in my head for half a second and dismissed it because switching disks is already a well-established thing
<whitequark>
but what i mean is like, inverse FUSE
<eddyb>
scott: ^^
<whitequark>
you'd need to simulate switching disks
<whitequark>
to flush cache
<whitequark>
if any
<whitequark>
even dos 6.22 had disk cache
<eddyb>
right, and you could have different modes depending on what you need to support
<eddyb>
(because Glasgow)
<eddyb>
this is the last thing I'll say because I feel this is turning into hyperfocus: take some random board, desolder some chip, decap it, reverse engineer it, emulate it in-circuit in Glasgow, rinse, repeat
<eddyb>
if you can emulate an ensemble of chips without needing external connections, even better, etc.
<whitequark>
eddyb: RE of a simple yamaha chip can take hundreds of hours
<whitequark>
like 500 for YM2151 iirc
<eddyb>
I'm not saying it would be a fast process
<eddyb>
but I could totally see myself doing this, or building tools to speed it up a bit here and there. it... sounds more fun than playing any game
<whitequark>
reverse factorio
<whitequark>
i mean
<eddyb>
omfg :D
<whitequark>
hang on
<whitequark>
did you say building tools
<whitequark>
we need tools for collaborating on chip vectorization
<whitequark>
i have something based on leaflet
<whitequark>
that needs to be upgraded
<eddyb>
oh I was actually curious about how that stuff is done today
<eddyb>
and what can be improved
<whitequark>
it's done with sarayan's ad-hoc python scripts.
<eddyb>
but never figured what to even ask about, it all seemed pretty opaque
<whitequark>
it is incredibly opaque
<eddyb>
hah
<whitequark>
it's like
<whitequark>
a step above tracing them by hand with a pencil
<eddyb>
I almost tried to do this by myself from one of the publicly available die shots of... I forget what chip
<eddyb>
like 2-3 years ago
<whitequark>
4004?
<eddyb>
and just gave up, but I didn't know people with previous experience in any of this
<eddyb>
it's been too long, I don't think I remember :(. I definitely looked at several chips
<eddyb>
(also, what I described about in-circuit replacement is kind of like that hypothetical process in some sci-fi stories, where you measure the parameters of each neuron then replace it with a simulacrum, and repeat this until you've digitized the entire brain, online and in-place)
<eddyb>
(except, vastly more doable :P)
<tnt>
mmm, I posted a link to some chip reverse engineering sw that was going to be released some time ago ... but I can't rememberit now :/
<whitequark>
eddyb: except glia
<whitequark>
you're thinking with glia at least as much as you're thinking with neurons
<eddyb>
whitequark: yeah, I mean, those stories barely scratch the surface
<whitequark>
eddyb: i relayed the cert to the appropriate people
<eddyb>
s/neuron/small units of the brain/ in what I said, I guess
<eddyb>
anyway, "reverse engineering is my passion, and preserving/recovering semantics in older technology is my obsession"
<eddyb>
if I could I'd spend all my time on that sort of stuff
<eddyb>
s/in/from
<tnt>
whitequark: does your irc logger archive have a search ?
<whitequark>
yes
<whitequark>
please take another look at the webpage..
<tnt>
oh, right ... my mistake was to start from the page of a specific day (in which case you only get result for that day which is ... not so useful)
<eddyb>
or, like, test a new tool on the 6502 images and compare against their netlists
<whitequark>
you can't do that
<whitequark>
like
<whitequark>
CMOS and NMOS die shots are super different
<eddyb>
oh?
<eddyb>
I mean, that fact makes sense, but I'm not sure what you mean. that you can't use the same tool for both?
<whitequark>
we have automated tools for CMOS but they don't work for NMSO
<whitequark>
and of course if you have standard cells like any modern tech it's totally different again
<whitequark>
you don't want to trace each single cell
<eddyb>
something I never asked is: do standard cells exist for yield and "we know this works so let's just repeat it" reasons?
<eddyb>
I always assumed there's a good explanation but last time I tried to find more info about standard cells I think I hit only deadends
<whitequark>
depends
<whitequark>
SRAM standard cells are ~always heavily optimized and won't pass DRC
<whitequark>
according to the manufacturer rules
<whitequark>
i think logic standard cells are usually more optimized than what you can do yourself and pass DRC, but that's more recent i think
<eddyb>
I guess transistor-level PnR would be a bottleneck, too?
<eddyb>
but it would make sense to optimize some small structure and then make that the primitive for everything built on top of that
<whitequark>
your synthesis tool doesn't give you transistors
<whitequark>
it gives you gates
<whitequark>
it doesn't make a whole lot of sense to synthesize to transistors because at that point you're no longer doing digital logic
<eddyb>
sorry, I just mean that placing individual transistors would be even more work, if you had to do it
<eddyb>
*more work for a tool
<eddyb>
whitequark: I'm starting to suspect ASICs are fabbed without the designer ever getting to see the standard cells, unless they delayer the product
<eddyb>
*many ASICs
<eddyb>
or I might've read that somewhere and forgotten, lol. yeah I should stop here
<whitequark>
no
<whitequark>
this does happen sometimes
<whitequark>
e.g. if you have SRAM or especially flash you put a placeholder in your GDS files
<whitequark>
and the fab fills it in
<whitequark>
because they're hella proprietary
<whitequark>
but for logic it's not generally the case afaik
<eddyb>
but still a good idea to base your design on standard cells unless you have weird requirements?
<whitequark>
standard cells or vendor cells?
<whitequark>
you could use your own standard cells so that e.g. your design is FOSS
<whitequark>
no one designs without standard cells anymore
<whitequark>
i mean, digital logic
<eddyb>
aaaaah, that's a piece I was missing, makes sense!
<eddyb>
whitequark: okay so coming back to more reasonable aspects: so the chips you're looking at are NMOS, and that makes it harder?
<whitequark>
yes
<whitequark>
well, some are CMOS
<eddyb>
oh god I just double-checked https://en.wikipedia.org/wiki/MOSFET and yupp I was confused this whole time about metal-oxide meaning two things not an oxide of a metal /facepalm
<eddyb>
whitequark: anyway if you have some samples, feel free to send it my way. I'll probably not do anything, but if I'm wasting time at some point, I might hack something together *shrug*
Sellerie has joined #glasgow
<whitequark>
i don't want something hacked together
<whitequark>
i have a fairly specific idea of what needs to be done
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjm6D
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] whitequark 7fdac59 - applet.interface.uart: move auto-baud control loop to FPGA.
<eddyb>
(like, I already have some ideas of using feedback loops to approximate the 2D layers and their 3D stacking, including letting you manually edit where it's not easily inferrable)