<Ultrasauce>
this sounds to me a bit like a hardware solution to a software problem
<Ultrasauce>
modulo some elaboration on 'confirming activity'
egg|laptop|egg has quit [Remote host closed the connection]
<whitequark>
eddyb: iirc PCIe has a different DC level on it depending on whether the link is on or off
<whitequark>
but check that on something that actually works
<whitequark>
i don't think either of your ideas will function
<eddyb>
Ultrasauce: I have a motherboard that gets stuck at bringing up a GPU, and refuses to attempt headless boot
<eddyb>
and I have no idea how far it gets before it gives up
<eddyb>
whitequark: ohhh, right, I forgot about DC offset. and thankfully I do have some working hardware to probe first. if it's slow enough I might even be able to correlate link bringup with POST code. thanks!
<d1b2>
<Attie> the FOSDEM 2021 talk on Glasgow has been accepted!
<d1b2>
<Attie> I'd better make a proper start on those slides now...
<whitequark>
Attie: nice!
<d1b2>
<Attie> @whitequark / @electronic_eel / @marcan / @tnt - I'd like to do a couple of "deep dives" into problems that have been resolved during the project, if you have particularly good / favorite ones, please let me know
<d1b2>
<Attie> if you'd like to keep it a surprise for the talk, email me - attie@attie.co.uk
<d1b2>
<Attie> I'm thinking that a general "buffering / fifo management" and the supply latch / lockup could be good
<whitequark>
hmm, the FX2 crossbar has been tricky to do, and the USB scheduling has been as well
<whitequark>
there's also yowasp
<d1b2>
<Attie> sounds good, i think both FX2 crossbar / USB scheduling might fit well with my ideas
<whitequark>
there are extensive source code comments about both
<d1b2>
<Attie> I'm heading offline now, but have a think / let's discuss when I'm back
<whitequark>
and i can fill in missing details to the extent of my ability
<d1b2>
<Attie> im sure! (I'll have a rummage too, but ty)
<eddyb>
I was gonna say that even an unpopulated slot goes to 0.37V immediatelly on powerup but looking at the pinout that pin was REFCLK+ lmao
<eddyb>
at least this cheap multimeter isn't completely useless,
<Yatekii>
Hey, question: Do I understand this correct, that I can write all the glasgow code in python, if I implement my own custom protocol decoder, so it compiles down to HDL automatically, loads it and runs my applet comminicating to it?
<whitequark>
Glasgow does not include anything like a "Python to RTL compiler"
<whitequark>
you use Python operations to construct a netlist explicitly with some library aid
<d1b2>
<Attie> yes... ish. the applet gateware is written in nMigen, which is in turn expressed in python
<whitequark>
fundamentally, you are using a HDL that has Python syntax and far fewer footguns than the more classical HDLs
<Yatekii>
I am aware
<whitequark>
right, it was not clear from the question
<Yatekii>
the thing is this: if I understand that right, one still needs to handle the transfer of data (glasgow <-> host (applet)) themselves, right?
<Yatekii>
so tzhere is no like automatic interface (because that would be awesome; not sure if doable)
<Yatekii>
yeah sorry, I was unclear :)
<whitequark>
define "handle themselves"
<whitequark>
on the device side, you have a FIFO, and on the host side, you have a socket-like interface with read()/write()
<whitequark>
you write the data to the FIFO and it appears when you call read() with no further involvement
<whitequark>
and vice versa
<Yatekii>
ah yes so this is handled, nice :)
<Yatekii>
so I guess there is some gateware that implements this interface so one can built their gateware on top and same for the applet side?
<whitequark>
basically yes, there is a bunch of logic that is instantiated when you request a device-side interfac
GNUmoon has quit [Remote host closed the connection]
<whitequark>
and a bunch more logic that runs in the python process when you request a host-side interface
<whitequark>
and then they get matched with each other, and voila: you can almost pretend it's TCP
GNUmoon has joined #glasgow
<whitequark>
the amount of work that went into making it nearly seamless was immense, i think it was quite literally months of improvements
<Yatekii>
awesome!
<Yatekii>
sounds like a real treat
<Yatekii>
I cannot wait for my glasgow to arrive :)
<Yatekii>
probe-rs interface here we go :D
<Yatekii>
you all did a really amazing job :)
<whitequark>
which chips?
<Yatekii>
hmm?
<whitequark>
what do you want to interface to probe-rs?
<whitequark>
electrically/logically
<Yatekii>
I want to make it support the glasgow as a probe :)
<whitequark>
if it is JTAG with probe-rs implementing the state machine, you might want to clone the jtag-openocd applet and modify it according to probe-rs needs
<Yatekii>
yes, that's most likely what i'm gonna do :)
<whitequark>
ok, sounds very good then
<whitequark>
i will add similar functionality for SWD later
<Yatekii>
yeah :)
<whitequark>
(have some higher priority tasks right now)
<whitequark>
for now, there will be some performance degradation because everything you do goes through python
<Yatekii>
yeah me too, namely: holidays :D but once I receive the glasgow I am sure I'll ahve more time :)
<whitequark>
one day, i think i want to implement the glasgow usb multiplexing code in rust and make the python stuff transparently run that so it can give away sockets to other clients
<Yatekii>
sounds awesome and easily doable :)
<whitequark>
basically, you would still run the python stuff so it builds gateware and initializes the applet, but after that python gets out of the way
<Yatekii>
I did quite some stuff with pyo3, was an awesome experience
<whitequark>
this is necessary because glasgow is only possible due to an extreme level of vertical integration, and i will not stabilize any of the internal interfaces
<whitequark>
but more direct access to the device is still something people will certainly need
<Yatekii>
yeah :)
<whitequark>
same for e.g. sigrok
<whitequark>
anyway, that is in quite some future
<Yatekii>
yeah :) I'd love to play a lot with it and also work on sigrok integration
<Yatekii>
but yeah as you know I have some projects going on already too :D
<Yatekii>
so those might be empty promises
<whitequark>
i am 100% fine with going slow, in fact i am more fine with it than going fast
<whitequark>
you can uh, see the amount of pull requests at the moment
<eddyb>
okay, that was some waste of time, I had to give up and pull the Fury out, I think I also disabled some slots when enabling the (terrible, gen2 x2) M.2 slot
<agg>
Yatekii: maybe a good use case for a network probe interface in probe-rs
<agg>
cmsis-dap commands over tcp socket or something
<eddyb>
but! in AC mode, my multimeter sees 0.2V on a PCIe lane when powered on, always in the first slot, but only when a card is inserted, into the second slot
<agg>
can use it for an ethernet probe, or for talking to glasgow software
<eddyb>
I'm guessing that's the PCIe MUXes at work?
<whitequark>
which muxes
<eddyb>
this is one of those motherboards with a bunch of those high-aspect-ratio chips that handle bifurcation
<whitequark>
ah
<whitequark>
yeah, probably
<eddyb>
I wonder if they rely on the presence detect signal. also, in weird configs, or when changing configs, really, the mobo has to restart in order to properly start, so I'm guessing it detects something changes, and leaves a reminder for itself for how to configure the MUXes or w/e
<whitequark>
something like that for both
<eddyb>
kinda interesting how many things sort of "have to be right" from power on (or reset, really)
<eddyb>
I was shocked to find out modern x86 CPUs still have config pins
<eddyb>
(and bifurcation config is one of those things, so I guess I have my answer for at least one reason it has to restart :P)
<whitequark>
does it actually change bifurcation?
<agg>
whitequark: would you consider any interface for running custom software on the fx2? that would be the other obvious way to interface glasgow as e.g. a cmsis-dap probe to any software application, but i appreciate it's not really in the usual workflow
<whitequark>
agg: i will not
<agg>
fair
<agg>
i have minimal interest in ever installing sdcc again anyway
<gruetzkopf>
the bifurcation straps on ivy bridge work
<eddyb>
it can do x8 + x8, at the very least, but I guess I'm not sure I've triggered that yet, hmpf
<Yatekii>
agg: could work :)
<whitequark>
agg: i am not going to prevent it, of course, but the support load we have with the current arrangement is already high, and multiplying that by custom firmware is a nonstarter
<Yatekii>
but I believe glasgow uses USB?
<eddyb>
(as in, this motherboard is capable of telling the CPU to split the first slot into two ports)
<gruetzkopf>
(1*16, 8+8, 8+4+4)
<agg>
Yatekii: glasgow is USB to the host software, but probe-rs somehow has to talk to the host software
<eddyb>
gruetzkopf: I believe that's kind of universal at this point. IIRC AM4 is the same?
<agg>
i.e. probe-rs would not talk to glasgow over USB directly at all
<agg>
at which point, a tcp socket seems nice, since we want one anyway for remote/ethernet probes
<Yatekii>
true :/
<agg>
and it would be v easy to wrap cmsis-dap into tcp
<whitequark>
i'm not sure if you can easily implement cmsis-dap in gateware
<eddyb>
(well, besides AM4 having an extra port for the x4 meant for M.2)
<whitequark>
i would expect you to stream jtag or swd commands directly
<Yatekii>
agg: full ack
<agg>
I bet it could fit into an hx8k but I agree, implement cmsis-dap processing in software and just swd+jtag on the gateware
<Yatekii>
bah I should not promise & plan things when old stuff is still not finished
<Yatekii>
fml
<agg>
so probe-rs would talk cmsis-dap to glasgow python, which translates that into swd/jtag over usb to the gateware
<whitequark>
i mean, it's possible cmsis-dap *is* nicely implementable, i couldn't find a clear overview i could glance over
<eddyb>
anyway, for the MUXes it could, say, downgrade the first slot, even with a card in it, then flip the MUXes to connect the second slot, and initialize that one. if it wanted to. but the CPU-side port config is fixed from reset, so it wouldn't do it any good
<agg>
honestly though cmsis-dap is basically some metadata and a simple wrapper for swd/jtag transactions, you probably could implement it entirely in gateware without that much woe
<whitequark>
agg: specifically interested in wire protocol
<whitequark>
aha
<whitequark>
ok that actually doesn't look too bad
<agg>
the wire protocol is byte oriented command-response, commands are one byte of command ID and more bytes of payload
<whitequark>
yes, i think that is actually nicely implementable in gateware
<eddyb>
this is gonna be interesting because the (Xeon E5) CPU has 40 lanes, so I'll start with nothing plugged in, and just measure the slots
<whitequark>
i would still suggest to start with jtag/swd streaming if you already implement that, but i expect that at some point a cmsis-dap applet will be a thing
<agg>
I think you'd probably still have python handle most of the commands just to save you the bother
<agg>
how would you communicate with the cmsis-dap applet?
<agg>
cmsis-dap is that wire protocol plus a USB interface - HID in v1 and a custom bulk EP in v2 - to talk to it
<agg>
and another bulk EP for streaming SWO data
<whitequark>
oh, is it not defined over network?
<agg>
no
<agg>
it's only USB
<whitequark>
oh :/
<whitequark>
ok that's kinda pointless then
<agg>
if you wanted glasgow to work with generic cmsis-dap software I think fx2 would need to expose the relevant endpoints
<agg>
(it's detected by an interface string containing the literal "CMSIS-DAP")
<whitequark>
yeah, i see why you mentioned that
<eddyb>
something something emulated USB devices (is that a thing?)
<whitequark>
i've considered it early on, but the longer i work on glasgow, the less fond i am on that idea
<whitequark>
*of
<whitequark>
there's just not that much space on fx2, and simultaneously, it is just doing too much Stuff
<agg>
I could imagine that being basically a totally separate thing: a firmware you can flash to glasgow's fx2 to turn it into a cmsis-dap probe temporarily, with a defined pinout
<whitequark>
some of which is safety relevant
<agg>
not officially supported or anything
<whitequark>
sure, people are of course free to do that, as long as they never ask me to support it
<agg>
just like, maybe I'd do that one day as a side project, since I've already implemented it twice elsewhere
<d1b2>
<TiltMeSenpai> bad idea: breakout usb on the lvds connector and bypass the fx2 (run in pure gateware)
<whitequark>
cursed
<whitequark>
very cursed
<agg>
in the meantime I think a better approach is define a cmsis-dap over ethernet
<whitequark>
and slow
<d1b2>
<TiltMeSenpai> lol hence bad idea
<d1b2>
<TiltMeSenpai> that's not a serious suggestion
<agg>
since we want to implement that in probe-rs anyway
<eddyb>
I was really happy to learn that v4l2loopback is a thing, frankly we need more device mockability
<eddyb>
why should hardware be required etc.
<agg>
downside: no other cmsis-dap software can work with it, only probe-rs, because it's not cmsis-dap standard
<agg>
upside: it still works with probe-rs?
<whitequark>
eddyb: i wish usb loopback was a thing
<whitequark>
i mean it is, usbip is a thing, it is just horrifying
<eddyb>
LD_PRELOAD libusb-using things? :P
<whitequark>
no?
<_whitenotifier>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JLSoO
<agg>
but anyway normal CMSIS-DAP HID is disappointing because it's so slow, there's been lots of interest in USB HS based probes which can get tens of Mbps of trace and log data off your target
<whitequark>
*that* one i do not argue with
<agg>
cmsis-dap HID is like 30kB/s on a very good day
<Yatekii>
oh lordy
<agg>
64 bytes per report, 1000 reports/sec, and you need a round trip for each one, so
<agg>
plus protocol overhead
<eddyb>
istg, I'm gonna rip a mobo in half at this rate, I hate 24-pin connectors so much
<eddyb>
anyway, uhh, REFCLK is dead on all but the shorter (chipset?) slot??
<agg>
don't know if you've come across RTT for instance, where the debug probe reads a circular buffer to pull log/trace/debug info off the target, it's much nicer when you have tens of Mbps instead of a few kbps
<agg>
`sudo modprobe uhid` here we go
<whitequark>
agg: meanwhile i have planned a very intricate system for pipelining JTAG requests such that the device itself could issue commands in a loop but without adding any segger-like per-target logic
<agg>
it's amazing how much performance typical implementations leave on the table, right?
<agg>
sounds great
<whitequark>
i just need to finish BoreSight support first
<eddyb>
can PCIe devices normally work without a reference clock?
<eddyb>
I would guess no, but who knows
<whitequark>
uhhh it depends
<whitequark>
in your case the answer is probably no
<whitequark>
but a reference clock is not strictly required for PCIe
<whitequark>
if you have spread spectrum enabled, which you probably do, i think it is required though
<eddyb>
so I'm pretty sure with how this motherboard is set up, there are 5 x16 slots (which get used at 5 * x8 with a 40-lane Xeon) and one x4 slot (always goes to the chipset AFAIK?)
<eddyb>
and only the latter has a working REFCLK
<d1b2>
<TiltMeSenpai> uhhh what
<whitequark>
only the latter has a REFCLK you can detect with your crude tools*
<eddyb>
I would expect there to be a shared line
<whitequark>
no
<whitequark>
each REFCLK is point to point
<eddyb>
oh huh
<whitequark>
since it is a transmission line you cannot just branch
<whitequark>
there are clock distribution ICs for this purpose
<eddyb>
so on the other mobo, all the slots had working REFCLK all the time
<whitequark>
(or clock generation ICs with multiple outputs)
<d1b2>
<TiltMeSenpai> pcie is a 100mhz refclk right
<eddyb>
maybe on this one they're gated
<whitequark>
yes
<gruetzkopf>
look at CLKREQ
<whitequark>
agg: so you've looked at SW-DP and JTAG-DP, right
<gruetzkopf>
and pull that to ground
<eddyb>
to be clear, on the Z97 (LGA1150) motherboard, empty slots had active REFCLK
<eddyb>
or at least they had a DC offset
<whitequark>
agg: don't you find it infuriating how the DP registers are like almost completely disjoint between the two
<eddyb>
so what I'm getting is each mobo could do it differently?
<gruetzkopf>
clkreq support is not mandantory for hosts
<gruetzkopf>
but fairly commin
<whitequark>
which you can only figure out once you understand both of those quite well
<eddyb>
I guess I'll look at lanes next, with or without the smol GPU plugged in
<gruetzkopf>
eddyb: take a single wire
<whitequark>
if it was written any worse, i would call it the documentation equivalent of a smug HN comment, but at least it is entirely accurate and admittedly useful, so i can't do that
<gruetzkopf>
plug it in between CLKREQ and the nearest ground
<agg>
whitequark: yes, urgh.
<whitequark>
agg: hahaha so it's not just me
<agg>
i have spent many unhappy hours with the various ADI docs open
<whitequark>
i feel like i could open a consultancy that does absolutely nothing but explains ADIv5 in plain language
<agg>
I always sort of wonder if it's because only like two or three companies need to read the docs to implement the debuggers that everyone else will then buy, and they can probably phone their mate at Arm
<agg>
but i've since discovered everyone is making ADI interfaces and probes and totally weird custom debuggers and everything else
<agg>
and your mate at Arm turns out to be useless too
<whitequark>
tbh, i derive some perverse enjoyment from figuring these puzzles out, but that absolutely does not mean i think they are good
<eddyb>
gruetzkopf: thanks, will try that next. just tried with the smol GPU in two different slots, and it didn't change their behavior
<whitequark>
yep
<eddyb>
the lanes on the x4 just stay at 0
<whitequark>
i have successfully taught ADIv5 to a small number of people and i feel like if i do this a few more times i should write a document that's just ADIv5 but like, in a way that makes sense
<eddyb>
I wonder if it has an asinine default CMOS :/
<gruetzkopf>
eddyb: if they're weird you also need to make the card present
Getorix has joined #glasgow
Getorix__ has quit [Ping timeout: 264 seconds]
<agg>
unfortunately as far as I can tell with this quick experiment, uhid allows you to send input events into the kernel, but you do not appear to other software enumerating HID devices
<agg>
and especially, lots of cmsis-dap software uses non-hid methods to enumerate USB devices first anyway, which would definitely not work
<agg>
USBIP could probably still work, I guess, but ew
<whitequark>
agg: i see
* whitequark
shudders
<whitequark>
i... no
<eddyb>
gruetzkopf: wow, the GPU has a completely unconnected CLKREQ#. but also, even with it plugged in (which should properly connect the presence detect), no change on the REFCLK
<whitequark>
i could not bear the thought of using usbip even for a demo
<whitequark>
and it would have been a pretty neat demo, too
<whitequark>
just.. you know the caveats with usbip right
<agg>
yea.. "don't"
<whitequark>
exactly
<agg>
would a USB FS device in hx8k silicon using Luna or something be so bad?
<whitequark>
someone who isn't me should implement usbip-but-not-bad
<agg>
it would be cool for applets to be able to appear as random USB devices to the computer
<whitequark>
:/
<agg>
fake USB floppy drives, hard drives, CMSIS-DAP probes, etc
<whitequark>
you can do floppies and hard drives
<agg>
you can't pretend to be an arbitrary USB device to do so, though, right?
<whitequark>
with uh. what was it. blknet?
<whitequark>
sure
<whitequark>
CBI UMS sucks anyway
<whitequark>
any floppy on glasgow would not want to use CBI
* agg
closes uhid demo, goes back to parsing SFDP
<whitequark>
you've seen the glasgow sfdp parser right?
<agg>
yea
<agg>
i do vaguely enjoy that glasgow sources are now a highly placed search result for each new thing i'm implementing in this program
<whitequark>
wait really?
<agg>
though i had already implemented all the sfdp 1.0 parsing by the time I found it
<agg>
hmm, I'm sure I came across it while searching, but cannot remember what I was searching for exactly
<eddyb>
oh wtf, why does this mobo have a ASM1187e?!
<eddyb>
I guess to make all the slots usable even w/o a 40-lane Xeon CPU?
<eddyb>
I wonder if it got really confused and put itself into a mode where the slots go to the PCIe switch but also it doesn't bring it up or something?
<eddyb>
and "i7 extreme" are not exactly cheap, to test with :/
<whitequark>
wait, is it advertised to work with the xeon?
<eddyb>
it's listed in the support tables
<whitequark>
is the firmware new enough for the xeon, too?
<eddyb>
heh that was the thing I was gonna look at next. at least this board has "BIOS Flashback" so I could try updating, in case it's that
<whitequark>
sometimes you have to reflash these with a different CPU to get them to boot with the one you want
<eddyb>
what's weird is, if it is that tho, why doesn't it just error with a POST code specific to "pls update me"
<whitequark>
it might be broken enough it can't even get that far
<whitequark>
like, completely nonfunctional microcode ROM
<whitequark>
this ... is a thing with intel
<eddyb>
it gets as far as complaining about a GPU, but, fair
<eddyb>
whitequark: the flash is a socketed DIP8, so worth case I shouldn't even need any motherboard functionality to update it, right?
<whitequark>
you can use glasgow to rewrite the flash easily
<eddyb>
<3
<whitequark>
(do NOT try to rewrite it while it is in the socket, pull it off or you will corrupt it almost certainly)
<whitequark>
*out
<whitequark>
(and make a damn backup first)
<eddyb>
heh, the button is in a corner, and got bumped slightly during shipping, so I was worried it wasn't working, but both it and its LED still work, so I'll try to official method
simukis__ has joined #glasgow
<whitequark>
button?
<eddyb>
the "BIOS Flashback" button, that flashes from an USB stick, w/o a working CPU or w/e
<eddyb>
presumably implemented with some cheap ARM microcontroller
<whitequark>
oh huh
<whitequark>
i had no idea it's a thing now
<whitequark>
that's pretty cool
simukis_ has quit [Ping timeout: 260 seconds]
<whitequark>
it also frees you from the necessity to extract the raw flash image from the firmware update, which can be... not trivial
<eddyb>
it's been a thing for a while on high-end motherboards (this was $700 new after all, and seems to sell for $350 used, I only have it because I was able to pay only like $55 for it :P)
<eddyb>
but it's becoming a standard feature on AM4 motherboards around and above $200, from what I hear
<whitequark>
well yeah it costs like a few dollars
<whitequark>
at best
<eddyb>
and for AM4 it's great value because you have all the CPU generations
<eddyb>
this reminds me AMD used to have a thing (maybe they still do) where they send you a cheap Athlon-branded APU on a loan, just to be able to flash a newer firmware on your motherboard lol
<eddyb>
oh this sucks ass, I need a MBR?
<eddyb>
time to go digging for an USB drive that is not an overengineered universal grub2+win10+NixOS mess
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #glasgow
simukis_ has joined #glasgow
simukis__ has quit [Ping timeout: 256 seconds]
<marcan>
whitequark: so what do you think about either 1) porting a C compiler to boneless, or 2) putting something else in glasgow that can run C code?
<marcan>
specific use case: I'm using a rando arduino for this USB-PD experimentation stuff, because (AIUI) the timeouts are too short to be piping everything to the host
<marcan>
it would be nice to just have a block you can dump in glasgow gateware, easily hook it up to glasgow fifos/pins, and shove C code into
<whitequark>
marcan: the plan was to do a python-to-boneless translator (of an extremely restricted python subset, more of a macroassembler than a compiler)
<marcan>
ah
<whitequark>
but i'm extremely overloaded with stuff
<marcan>
yeah
<whitequark>
i mean we don't even support windows properly yet
<marcan>
as you know I have a Fun Project for next year, but the scope is broad enough to allocate time for things like glasgow and other open source projects :)
* whitequark
nods
<marcan>
so I hope to be able to shift things in that direction too
<marcan>
(it's going to be a bit of a lifestyle change... suddenly working in open source as a job)
<whitequark>
do you think you could finish upstreaming stuff we have in kicad? that or just close it
<whitequark>
i've had a notification in my head for two years that i should remind you to do it
<marcan>
yeah, definitely, will alloc some time for that very soon, just give me a sec
<whitequark>
ack
<whitequark>
we don't have any more than the open issues, i think, since aiui esden didn't really follow klc with the revC2 changes
<whitequark>
if something it was the opposite
<whitequark>
which is fine, but it would be a shame if the work we did do to KLC standards went nowhere
<whitequark>
semi-related: anyone wants to update our CI to use GHA?
<whitequark>
Travis basically killed their OSS offering
<whitequark>
Attie maybe?
<kmc>
what's boneless? a soft core for the glasgow fpga?
<whitequark>
it's sort of a weird mix between SPARC, 8051, Thumb-2, and MIPS
<whitequark>
the original goal was to fit a feature rich 16-bit CPU into 300 4-LUTs, but that turned out a bit too ambitious
<whitequark>
nevertheless it is pretty small
<kmc>
cool
<whitequark>
while being, yes, feature-rich, and with an extremely regular ISA
<whitequark>
you have everything from a ton of ALU instructions with both register, immediate, and wide immediate forms, to single-instruction coroutine switching
<whitequark>
i've still yet to finish some aspects of the ISA and reference implementation; somewhere in the middle i had to implement nmigen
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
<eddyb>
argh this stupid motherboard is refusing to take my USB drive. I've tried various file name combinations, and even decided to skip MBR and just format the entire thing as one FAT32 partition (turns out `gparted` calls this a `loop` "partition table"?)
<eddyb>
and the flashback thing can just signal an error, not let me know what's wrong :/
<eddyb>
it is accessing the USB stick, because this one happens to have a light, but other than that, idk
<eddyb>
it's a baffling board, slowly realizing how much probing I might need to do before I can make any sense of it
<eddyb>
(I've also seen some worrying suggestions online that X99 is cursed and boards died randomly all the time :/)
<eddyb>
whitequark: even if I do nothing else, I should be able to figure out which version it has already by reading the SPI flash, right?
<eddyb>
presumably I have to pull it out of the socket to do that?
<whitequark>
yes and yes
<whitequark>
the pinout is in the memory-25x --help
<eddyb>
nice :D. hopefully I should be able to just hold it in mid-air with grabbers
<whitequark>
yes
<whitequark>
make sure to connect ~HOLD
<whitequark>
even though that doesn't do anything, if you leave it floating, the flash will misbehave
<eddyb>
oh boy
<whitequark>
(as in, glasgow drives it as a constant 1)
<whitequark>
(for some silly reason there's no pullup usually...)
<eddyb>
one fun thought I just had is maybe digging for some random UART output coming from the microcontroller used to implement "BIOS Flashback"
<whitequark>
sure
<whitequark>
a scope would be quite useful for that
<eddyb>
rriiight
<eddyb>
one thing I'm a bit scared about with grabbers, is shorting out adjacent pins accidentally
<kmc>
i had some questions about the glasgow design after looking at the schematics and firmware
<whitequark>
eddyb: in general, SPI flashes are shockingly resilient
<whitequark>
i've ran some 1.8V only flashes at 5V and they survived
<eddyb>
ah, no, that's DIP, I'm more worried if I start poking around at random chips
<whitequark>
don't count on that, but... it's pretty unlikely you'll manage to actually destroy it by accident
<kmc>
for example, this 'recovery' jumper, it changes the address on the FX2 I2C flash, is that so that the FX2 will decide that no flash is connected and go into some default mode? what is stored in the external flash versus internally?
<whitequark>
oh
<whitequark>
kmc: correct, except it *probably* doesn't have internal boot ROM
<whitequark>
it has an USB endpoint where you can give it memory read/write commands and tell it to start the CPU
<whitequark>
which seems to be hardcoded in silicon
<whitequark>
and a default configuration descriptor that lets your OS recognize it
<eddyb>
neat
<kmc>
I see
<whitequark>
so basically if you hit "recover", you DMA the proper boot code into its RAM and start it up
<kmc>
and in normal operation it boots from the I2C EEPROM?
<whitequark>
kind of a strange design, and definitely insecure in the sense that anyone can reprogram any FX2 device they have access to to e.g. impersonate a keyboard, but it is definitely unbrickable
<whitequark>
normally, it reads a header from the I2C EEPROM that at the bare minimum contains VID/PID/DID
<whitequark>
and some glasgow-specific stuff
<whitequark>
it may also optionally contain firmware, or it may not; firmware is required for winusb driver to be bound on first plug, but other than that, glasgow software will load it transparently
<whitequark>
(this is very handy when developing firmware)
<_whitenotifier>
[glasgow] adamgreig opened pull request #251: Add GHA CI - https://git.io/JLSXy
<kmc>
I see
<whitequark>
basically, the idea is that if you have a glasgow and a usb cable, this is the most you will possibly need (besides host software)
<whitequark>
ok, i mean, assuming you can find any piece of metal.
<whitequark>
it would be pretty dumb if it had a potential "who programs the programmer" failure mode
<whitequark>
this is one of the multiple good reasons why it does not implement USB stack in gateware, instead opting to use a 8051 instead
<agg>
bedtime here, I can look into adding caching later if you like, though it doesn't seem like much time is spent installing things compared to running it actually
<whitequark>
nope, fine as it is
<whitequark>
8m vs 10m makes little difference
<_whitenotifier>
[GlasgowEmbedded/glasgow] whitequark created branch revC2 https://git.io/JLS1N
<_whitenotifier>
[glasgow] whitequark created branch revC2 - https://git.io/fhhGp
<eddyb>
current status: doing a very slow non-"Quick Format" from win10 just in case it makes things work all of a sudden
<whitequark>
that would be shocking if it did
<eddyb>
nope, did not :(. tho I am reminded of that time I accidentally ended up with two overlapping filesystems on one USB drive (one of them from a dd'd `.iso`, I think?)
<eddyb>
could not get rid of that until I `dd if=/dev/zero`'d the damn thing
<eddyb>
since it's in that weird gap bootloaders use
<whitequark>
yes
<eddyb>
interesting, if I nuke the MBR on linux, then plug it into windows, and let it format when it asks me to, it doesn't create a MBR, just formats the whole thing as FAT32 directly (like the "loop" ""partition"" in `gparted`)
<whitequark>
yes, and in fact windows cannot access any partition past the 1st on thumbdrives
<eddyb>
but at this point I think I should just sleep and hopefully get woken up by the delivery that includes what I'll need to use Glasgow :P
<whitequark>
(or at least it used to not be able to do that)
<_whitenotifier>
[glasgow] attie synchronize pull request #213: Add support for Out-of-Tree applets - https://git.io/JTfm8
<_whitenotifier>
[glasgow] attie synchronize pull request #213: Add support for Out-of-Tree applets - https://git.io/JTfm8
<_whitenotifier>
[glasgow] whitequark commented on pull request #213: Add support for Out-of-Tree applets - https://git.io/JLS7K
<_whitenotifier>
[glasgow] attie commented on pull request #213: Add support for Out-of-Tree applets - https://git.io/JLS7P
<_whitenotifier>
[glasgow] attie closed pull request #213: Add support for Out-of-Tree applets - https://git.io/JTfm8
<_whitenotifier>
[glasgow] whitequark commented on pull request #213: Add support for Out-of-Tree applets - https://git.io/JLS77
<_whitenotifier>
[glasgow] attie commented on pull request #213: Add support for Out-of-Tree applets - https://git.io/JLS7p
<_whitenotifier>
[glasgow] whitequark commented on pull request #213: Add support for Out-of-Tree applets - https://git.io/JLS5I
<d1b2>
<Attie> @wq, re #179... i was thinking about that a while ago... up for a chat now if you are
<whitequark>
attie: sure
<whitequark>
so basically the idea is to have a very similar interface to bits() except mutable, and for the backing storage, instead of an int(), have a python array() object backed by the machine word
<d1b2>
<Attie> ok
<whitequark>
i will be very grateful if you implement it since that will eliminate one of the largest obstacles to windows support, as well as just largest papercuts in general
<whitequark>
please do post your work in progress as a draft PR so we can stay in sync on how it works
<d1b2>
<Attie> sounds good - i'll need to read up on bitarray a little, and see what's what
<d1b2>
<Attie> i presume the concept is as it sounds though, so not tooo scary
<d1b2>
<Attie> re draft pr: will do
<whitequark>
like a list of bool but faster
<whitequark>
and also with absolutely HORRIFYING footguns
<d1b2>
<Attie> yep / heh
cyborg_ar has joined #glasgow
<whitequark>
migrating to bits() in JTAG code has singlehandedly eliminated the biggest source of bugs in it
<d1b2>
<Attie> oof, a nice move then
<d1b2>
<Attie> "All functionality implemented in C" - i'm guessing that's the issue for Windows?
<whitequark>
well it is also a C extension (of very doubtful quality) that doesn't have binary wheels
<whitequark>
yes, it is. and it is an issue for linux too
<d1b2>
<Attie> ah
<whitequark>
cpython extensions are really not something i ever want to have in glasgow
<whitequark>
ctypes/cffi is a different story entirely
<cyborg_ar>
i just preordered a board
<cyborg_ar>
i be excite
<whitequark>
nice! :D
<d1b2>
<Attie> just looking at the places bitarray is used, i don't think i'll be able to do in-situ testing
<cyborg_ar>
one thing im eyeing in that LVDS connector. i wonder if anyone has in mind developing an analog hat for it
<whitequark>
Attie: i would expect you to reuse the bits() testcases and then add mutable ones like there are pure ones currently
<whitequark>
an easy way to do a smoke test is to s/bits/bitarray/ in all the JTAG code
<whitequark>
once you are done i will recheck with those particular devices, i believe i still have them
<d1b2>
<Attie> sure
<whitequark>
really wish our HiL testing framework was more mature, but oh well
<d1b2>
<Attie> that would indeed be nice
<whitequark>
(and improving it would drag a tail of other issues, so not trivial either...)
<d1b2>
<Attie> i setup a company trying to do more HiL testing a while ago... it seems to be a difficult sell
<whitequark>
tbh, in this case the problem is a combination of glasgow software being (to be frank) very immature yet in wide use, and the fact that i have not had much experience doing this sort of thing before i wrote it
<whitequark>
i think the architecture of glasgow makes it inherently easier than in most cases
<whitequark>
but i failed to exploit that
<d1b2>
<theorbtwo> Careful with feeling like it is in wide use, or you will get the make problem, where they thought about fixing the tabs Vs spaces thing early on, but decided not to because it would break comparability with the tens of makefiles already in use.
<d1b2>
<theorbtwo> ...or Perl's slow death by backward compatibility, but that's a little to personal for me to go in to more detail.
<whitequark>
theorbtwo: one benefit of Glasgow's extreme level of vertical integration is that I can make cross-cutting changes easily
<whitequark>
this will change once we have out-of-tree applets, which is a good reason to submit your applets in-tree
<whitequark>
for now, the "wide use" part mostly means that any changes must be gradual and keep the in-tree applets actually functional
<whitequark>
since there are already enough of them that changing all the applets in a single commit is not something a single person can viably do
<whitequark>
cyborg_ar: the LVDS connector mostly exists so that we don't waste I/O for no good reason
<whitequark>
we don't really have any specific intended use for it, and I suspect that it will stay "unofficial"
<whitequark>
we don't intend to preserve it on other generations either
<whitequark>
it's just something extra you get as a courtesy, but which is totally unsupported
<cyborg_ar>
i imagined as much
<cyborg_ar>
i'm having a look through the applets.
<cyborg_ar>
i like that it can emulate an i2c peripheral/target
<whitequark>
yep, though that requires clock stretching
<whitequark>
which... is a tall order
<cyborg_ar>
luckily all my i2c designs require stretching anyway
<cyborg_ar>
i try not to deal with cursed ones
<whitequark>
convenient! also you can modify the i2c target applet to do everything on the FPGA
<cyborg_ar>
*cough*raspberry pi*cough*
<whitequark>
but that can only be done per use case, not in general
<cyborg_ar>
yeah you cant really compile all of python into hdl i would guess
<whitequark>
you don't really ever compile python into hdl in glasgow
<cyborg_ar>
but you can implement arbitrarily complicated state machines in the fpga as long as they fit
<whitequark>
you construct netlists with a bit of syntactic sugar
<whitequark>
that tends to scale a lot better as your design complexity increases
<cyborg_ar>
yeah i am looking in some applets. it is nice
<cyborg_ar>
even for weird fun stuff the code is not too horrifying
<cyborg_ar>
like the floppy drive applet
<whitequark>
yup
<whitequark>
the floppy drive applet is basically a logic analyzer at the moment
<whitequark>
i have plans for a gateware demodulator but it's been a while since i could give it attention
<cyborg_ar>
also i like the idea that, performance allowing you can prototype shit in python using software before you move it to hardware space (if ever needed)
<whitequark>
yep
<whitequark>
heavily biased towards rapid prototyping
<cyborg_ar>
a lot of the stuff i want to interface to is weird old stuff from the 80's so speed is secondary to oddness
<whitequark>
because let's face it, many if not most applets will be weird one-off stuff you really don't want to do fully in HDL
<cyborg_ar>
yup
<whitequark>
i see my decision to use TTL-compatible drivers pays off :D
<cyborg_ar>
yes
<cyborg_ar>
that is the one thing that made me hit buy
<whitequark>
wow, nice
<whitequark>
early on, azonenberg (who partly inspired this) was all like "who needs 5V? do 3V3 only" and i vehemently disagreed
<cyborg_ar>
i always dread having to rig up my own level shifters
<whitequark>
there's barely any stuff left that can do 5V so glasgow being able to do it natively could fill a lot of roles
<d1b2>
<theorbtwo> Without ttl-compatable drivers it is mostly just another FPGA Dev board, no?
<cyborg_ar>
but he has his lab decked out with the latest equipment. the only high quality equipment i can afford is from the 80's and 90s and i like to talk with it :)
<whitequark>
theorbtwo: no, not really, you still have the software stack that does rapid prototyping and customization like nothing else
<whitequark>
(because it is the first thing that really takes the advantage of the FOSS toolchain. nothing else had a chance to even try and compete!)
<cyborg_ar>
its crazy how much new life can be breathed into old equipment with the right software and some hw mods
<whitequark>
yup
<d1b2>
<theorbtwo> I meant the hardware, not the software. The software mostly just needs a fx2+FPGA board, and that's a pretty common archetchture, aiui.
<whitequark>
you still have the configurable bank voltage and pulls, but more importantly, you don't actually have to mess with the fx2 yourself
<cyborg_ar>
yeah i like the fact that it has sturdiness designed in, perhaps the one thing that may leave me wanting a bit is that the amount of IO is a bit limited for the wide and slow buses from the 80s, but i could easily make a board with multiplexers and do some gateware i think to deal with that, since the bus is so slow compared to what glasgow can do
<cyborg_ar>
ah yeah i am glad someone else is doing all the fx2
<cyborg_ar>
it is an AMAZING micro, but ew
<whitequark>
there are two things to address that, the next revision will have double the IO
<whitequark>
and i have also completely reverse-engineered the last true 5V CPLD family
<whitequark>
for use primarily as a programmable pin expander.
<cyborg_ar>
neat
<whitequark>
the only thing that's left is to draw some diagrams that explain how the macrocell actually works
<d1b2>
<theorbtwo> I expect that if Glasgow really takes off, there will be a small explosion of boards that are mostly Glasgow but with as much as you easily can made not-configurable.
<cyborg_ar>
yeah really wide buses IME are really slow buses, unless you are trying to trace out a mid/late 90s+ PC
<whitequark>
because it is hair-tearingly insane and basically nothing that is in the datasheet actually applies
<whitequark>
almost as if the macrocell was optimized by a genetic algorithm or something
<d1b2>
<theorbtwo> Sounds like ... Fun.
<whitequark>
i mean i know how it works
<whitequark>
i just can't explain it to anyone else
<cyborg_ar>
you are cursed with the knowledge
<gruetzkopf>
currently building a frontend board for the most insane late 70s bus i know of
<cyborg_ar>
it's like the book the giver
<gruetzkopf>
(which AFAIK was is used in railway systems in/around germany)
<whitequark>
theorbtwo: re glasgow derivatives, quite likely. i mean, i know people already do tear off chunks of the glasgow gateware/software and graft it onto completely unrelated designs
<whitequark>
it's designed in a modular way so that this is (a) possible, (b) something i can entirely refuse to support in any way
<cyborg_ar>
whitequark: you are one of the receivers of cursed technical knowledge, so the rest of society doesnt have to deal with it
<whitequark>
unfortunately true
<whitequark>
i think i know more about that CPLD than anyone still left at the vendor that makes it
<d1b2>
<theorbtwo> Sounds handy. Maybe even better, you can refuse to support until you are paid to do so.
<whitequark>
... assuming anyone from the original team is still left, which is probably not the case...
<cyborg_ar>
yeah that is too often a case
<whitequark>
theorbtwo: no, it is a philosophical position, not an economical one. once exponential explosion of the feature matrix starts, no amount of cash can make things work well
<cyborg_ar>
in a previous job i was maintaining some CPU boards from 1986, the company that made them didnt exist anymore. i reverse engineered both the HW and FW, even fixed some ancient bugs in the rom in the process
<cyborg_ar>
it was fun
<whitequark>
the first thing you'll bump into (assuming you can actually test the entire matrix) is maintainer bandwidth
<whitequark>
you know the old principle where adding people to a late project makes it more late? same deal
<cyborg_ar>
yeah it makes total sense
<d1b2>
<theorbtwo> Oh, I didn't mean to imply that you'd take a job working on the entire matrix, just some consulting work with folks working on a Glasgow derivative from time to time.
<whitequark>
cyborg_ar: fortunately microchip will keep making atf15xx while they still have people buying those, and a shocking amount of people are buying atf15xxas
<cyborg_ar>
whitequark: i think the ideal for everyone is if you can get the unicorn of not HAVING to support it because it's not needed
<whitequark>
(ok, it is possible they will break the line and/or the masks before demand ceases, they are seemingly still using masks and litho from 1999)
<cyborg_ar>
microchip still makes the PIC16F84, nuff said
<whitequark>
(i've asked and it looks like they basically still have the original line that makes atf15xxas and it does literally nothing else because who even needs lines that ancient)
<cyborg_ar>
has it been what, 20 years since they released the 16F627?
<whitequark>
cyborg_ar: i always have to support it because no derivative is perfect
<sorear>
wait, the 5V CPLD used as an on-board IO expander?
<whitequark>
sorear: there is no CPLD at the moment
<cyborg_ar>
yeah, that is one thing i do like about microchip, they will keep making parts forever, with the same bugs
<whitequark>
i just reverse-engineered the bitstream
<whitequark>
cyborg_ar: yeah, pretty lucky in that case, because literally every other vendor has dropped 5V CPLDs long ago
<whitequark>
and microchip didn't even bother to NRND it
<cyborg_ar>
yeah they must be making enough
<cyborg_ar>
maybe for some missiles
<cyborg_ar>
haha
<whitequark>
i've asked and they sell them in quite significant volume
<whitequark>
i mean mouser has thousands in stock even
<whitequark>
with a few weeks before the next delivery
<whitequark>
whoever is using those CPLDs for whatever reason, they sure go through a lot of them
<cyborg_ar>
well they have the entire market of 5v cplds now
<sorear>
good thing >5V seems to be very rare
<whitequark>
sorear: depends on the field really
<whitequark>
telecom, automotive
<cyborg_ar>
yeah outside of microelectronics, not that rare
<whitequark>
and in microelectronics, 5V is already very rare
<cyborg_ar>
yeah
<cyborg_ar>
you only see it in old buses like RS485, which is not very micro
<cyborg_ar>
or some old CMOS sensors
<whitequark>
revD will be the last glasgow revision to support 5V, revE will be 3V3 natively, though you could slap the revCD frontend on it of course
<whitequark>
tbh, the part that probably carries the most obsolescence hazard on glasgow is the FPGA
<cyborg_ar>
in a project i had to do a while ago i had to interface with a CMOS line sensor that was 5 volt only
<cyborg_ar>
not ttl
<cyborg_ar>
cmos 5 volt
<cyborg_ar>
so 3.3v levels were out of spec
<cyborg_ar>
i used a greenpak to do both level shifting and a simple state machine to offload the CPU a bit
<whitequark>
ooooh greenpaks!
<cyborg_ar>
greenpaks are the only tiny programmable thingies i know that support 5 volts
<whitequark>
i did some early GP4 work, which was the first FPGA ever supported by FOSS tools
<whitequark>
(yes, not ice40, gp4)
<cyborg_ar>
i used GP5, with the silly schematic tool they have
<cyborg_ar>
gp4 was too annoying with the dual bank
<whitequark>
gp5 is a lot more convenient to program
<d1b2>
<daveshah> My gut feeling is that iCE40s will be around for a while longer; given Lattice don't really have a replacement yet
<whitequark>
gp4 is super slow laso
<whitequark>
daveshah: yeah, certainly
<cyborg_ar>
tbh given the simplicity and limited amount of LUTs, drawing a schematic is not a bad way to program those parts
<whitequark>
i'm mostly thinking ahead, seeing as glasgow is not something that i expect to be a fad for a few years
<d1b2>
<daveshah> The package that the Glasgow uses is a bit of an obscure one - added later than the others and less available - so there is perhaps a low risk there
<d1b2>
<daveshah> Yeah
<d1b2>
<theorbtwo> I have a boiler I would like to interface 2irh that uses 0 9-12 v, 1 15-24v
<cyborg_ar>
i feel i would be bumping my head against it not synthesizing if i was trying to write HDL for them
<whitequark>
cyborg_ar: the thing where gp4 has two crossbars is aggravating to do manually
<whitequark>
not sure if gp5 has that
<cyborg_ar>
yeah
<sorear>
is ice28 anywhere close to shipping yet?
<cyborg_ar>
gp5 is a single frabric
<whitequark>
ah
<cyborg_ar>
you can connect everything to pretty much everything
<d1b2>
<daveshah> they haven't even announced an ice40 successor on the 28nm process yet
<whitequark>
is it a die shrink?
<d1b2>
<daveshah> no, it's a totally different arch
<cyborg_ar>
but again, it is like what, 2 dozen LEs
<cyborg_ar>
wiring them up by hand is not too horrible
<cyborg_ar>
also one silly thing i love about the GP5 is that you can edit the bitstream through I2C
<d1b2>
<daveshah> the closest iCE40 replacement would probably be the LIFCL-17 which is supposed to ship in April
<cyborg_ar>
i used it in my application
<whitequark>
cyborg_ar: yep, it's neat
<whitequark>
you can live edit the fuses of atf15xxbe
<d1b2>
<daveshah> but I think at some point they will do a 'iCE NX' that's a more direct iCE40 successor
<cyborg_ar>
the MCU patches the bitstream to change the delays in the state machine
<whitequark>
irritatingly they only sell the BE chips in quantities of what is likely one wafer
<whitequark>
it's cheap although not dirt cheap
<whitequark>
i'm gonna grab some at one point. no 5v tho.
<sorear>
if ice40 stopped existing tomorrow and a replacement 16-IO USB glasgow had to be developed using a different FPGA family, would it still be called a "revC"?
<cyborg_ar>
a gp5 would be neat to have in something like glasgow but i dont think anyone worked out a toolchain to work with it in the open. the bitstream is fully documented iirc (that's how i knew where to patch to do my counter changes)
<whitequark>
sorear: yes
<whitequark>
the "revision" is basically the user interface
<whitequark>
the specific FPGA is an implementation detail
<cyborg_ar>
iirc some time ago silego was semi-supporting the work zoidberg was doing with the GP4, but then they got bought out by dialog
<d1b2>
<daveshah> This feels very hypothetical, iCE65 was deprecated years ago and Rochester have enough of many variants to build plenty of Glasgows
<d1b2>
<daveshah> but noone really cared about that, and the fact they are recommending a move to iCE40LP suggests that LP/HX aren't going anywhere soon
<d1b2>
<daveshah> yeah
<whitequark>
... what was LM anyway
<d1b2>
<daveshah> iCE40LP with hard IP literally glued to it
<whitequark>
ok well maybe they have similar feelings about it as we do
<sorear>
soc fpga, run all necessary software on-board, replace USB with a rs232 console login [hides]
<d1b2>
<daveshah> they still connect to the hard IP via IO tiles - I think they just took the LP GDS2 and added the hard IP next to it
<whitequark>
sorear: you've just invented blackmagic probe
<whitequark>
except kind of not really because glasgow is useful because you can do all sorts of fun stuff on the host
<whitequark>
which is also why we don't package it as docker images or something like that
<cyborg_ar>
i am just excited with the prospect of being able to interact with weird hardware without having to write C or HDL
<cyborg_ar>
snakes all the way down
<whitequark>
yep, kind of why i wrote it
<whitequark>
very tired of a situation where i have the hardware and i know how to use it but actually doing that is tedious beyond any reason
<cyborg_ar>
i just want to connect to my jupyter server and start finger painting
<whitequark>
hahahah
<d1b2>
<Uwe> For JTAG with the Glasgow, please also consider writing a blackmagig backend...
<cyborg_ar>
whitequark: tell that to me, i was feeling so giddy when i found out about circuitpython and would not need to deal with a C compiler to play around with an i2c thingamajig again
<whitequark>
uwe: what would be involved?
<cyborg_ar>
or do simple arduinoey things
<whitequark>
i'm not *hugely* fond of circuitpython but it certainly does have its applications
<whitequark>
(i might be unfair to it, i should take a closer look)
<cyborg_ar>
it is definitely not perfect
<d1b2>
<Attie> @whitequark I spotted a missing oe.eq(1) on #228 (causing a non-functional UART Tx)... adding it causes the test to fail
<cyborg_ar>
it is slow and limited, but you can also use a horribly oversized MCU with it and do shit you could do in C++ with arduino... but in a repl
<cyborg_ar>
with a text editor
<cyborg_ar>
without installing software
<d1b2>
<Uwe> Some way to detect the glasgow via usb VID/PID and perhaps description, and implementing the JTAG primitives, probably similar to the primitives in openocd.
<d1b2>
<Attie> am I correct in thinking that TSTriple() maps to nmigen.lib.io.Pin
<whitequark>
uwe: you can already use glasgow with openocd though
<whitequark>
as for usb vid/pid, direct usb access to glasgow from third party software is not supported (and will not be supported)
<d1b2>
<Uwe> But you need a lot of config files.
<cyborg_ar>
yeah wasnt the whole thing about BMP that it ran a gcc server on the board? i dont think you can run a gcc server in the FPGA or the FX2, if you are running a server on the PC why not openocd
<whitequark>
there will be a coresight debugger in glasgow itself
<d1b2>
<Uwe> BMP can run as a server in the firmware or on a host,
<d1b2>
<Attie> ah, nm... i dug into it and think I've found the answer
<whitequark>
for... various reasons, like being able to pipeline JTAG requests, and to be able to work with hardware that is too broken to be used with openocd
<whitequark>
(such as a mediatek chip i have which mediatek ardently insists does not have JTAG)
<whitequark>
(i can definitely dump stuff through AXI though. so much for not having JTAG)
<whitequark>
(but it drives openocd nuts)
<d1b2>
<Uwe> If the glasgow exposed it's interface in by some other librarty, that is fine too.
<cyborg_ar>
maybe its like processed cheese product, they cant call it cheese, they cant call it JTAG
<whitequark>
uwe: the normal way for glasgow to expose itself to other software is through sockets
<whitequark>
cyborg_ar: no that's the msp430 jtag, or rather i wish it was
<whitequark>
because whatever that thing is, it is definitely not jtag
<cyborg_ar>
i cant believe it's not jtag
<whitequark>
processed jtag product lol
<russss>
you could presumably have a glasgow app which creates a socket which speaks the GCC debugger protocol
<whitequark>
russss: yep and that is already done for MIPS
<whitequark>
however doing *everything* in python has some disadvantages along the advantages
<d1b2>
<Uwe> Well, BMP on the host exports the gdb server via a socket, why not use another socket to talk to the debugger.
<whitequark>
it is definitely useful to let other software speak almost-directly to the device
<russss>
ah cool. Well, I have a BMP anyway so I'll probably keep using that because it's nice
<whitequark>
uwe: there was this talk of extending CMSIS-DAP protocol so that it can be done over the network
<cyborg_ar>
noo you cant write high performance software in python. haha snake go brrr
<whitequark>
that is something i would be in favor of providing
<d1b2>
<tobbad> I just looked at glasgow schematics: Why are IO 4-7 on J2/J3 not protected to overvoltage. VIO is not connected to D21/D23 on revC2?
<d1b2>
<Uwe> @russss, BMP is the hardware with firmware but now also a PC hosted program.
<whitequark>
oh i didn't realize that about BMP
<_whitenotifier>
[glasgow] attie commented on pull request #228: applet.interface.uart: convert to nmigen - https://git.io/JLSNe
<whitequark>
Attie: yes re Pin
<d1b2>
<Uwe> BMP can talk to CMSIS-DAP probes already.
<russss>
I did not know this either
<whitequark>
uwe: glasgow won't export CMSIS-DAP directly because it is not designed to impersonate different stuff over USB
<whitequark>
so unless CMSIS-DAP would be extended to work over the network too, it can't be used here
<whitequark>
however now that we have two projects (probe-rs, bmp) interested in CMSIS-DAP like capability in glasgow i am even more in favor of providing it (over the network)
<d1b2>
<Uwe> @whitequark: If you tell"as for usb vid/pid, direct usb access to glasgow from third party software is not supported (and will not be supported)" is the code providing the socket access to the glasgow closed source?
<whitequark>
everything is open source
<gruetzkopf>
but the usb interface is explicitely not stable
<gruetzkopf>
and will not stay on usb
<whitequark>
however, the usb interface is not stable, the fx2 firmware is not stable, and i *will* break them when i need it
<cyborg_ar>
is any usb interface ever?
<d1b2>
<Uwe> So how does one connect the glasgow to the PC?
<d1b2>
<Uwe> If USB is not stable, connection can not be stabel?
<cyborg_ar>
you wait another year and connect it with ethernet
<cyborg_ar>
:P
<whitequark>
by "not stable" i mean "it will change without warning"
<whitequark>
not "it works badly"
<whitequark>
it is not a stable API
<cyborg_ar>
yeah and it would be burdensome to maintain that
<whitequark>
whatever happens on USB is an implementation detail shared between glasgow python software and firmware
<whitequark>
you can do whatever you want with the software, firmware, and hardware because it is OSS, but you are entirely on your own
<cyborg_ar>
but since everything is open you could in theory develop whatever fx2 firmware to make the hardware work with other software
<cyborg_ar>
i do like that architecture, nice python porcelain over some sausage factory i dont have to care about
<cyborg_ar>
because whitequark is already tearing her hair on it making sure it doesnt leak :P
<cyborg_ar>
or doesnt leak much
<whitequark>
like i mentioned earlier today, at some later point there will also be a way to not have python on your hot path, but this will be transparent to 3rd party software
<whitequark>
you will just get a socket, like before
<whitequark>
cyborg_ar: it leaks very little, not much more than TCP does
<whitequark>
which was a real nightmare to achieve
<cyborg_ar>
i bet
<cyborg_ar>
i have been following your twitter
<whitequark>
have still yet to make it work as well on windows as it does on linux
<cyborg_ar>
that was another inch closer to the buy button, the amount of care put in the thing
<whitequark>
hehe :D
<cyborg_ar>
good for me windows support is almost completely irrelevant, but i understand the importance
<cyborg_ar>
the nice thing is that you dont have to support windows 7 anymore
<cyborg_ar>
what a fucking nightmare
<d1b2>
<Uwe> That is always a pain. An then MacOS support when one has no MacOS machine...
<whitequark>
windows support is already better than probably the vast majority of OSS, but i believe it has to be completely turnkey
<whitequark>
and making it completely turnkey involves making changes through the entire ecosystem
<cyborg_ar>
10 is so much easier to support
<whitequark>
at one point i was working on 32-bit x86 in wasmtime...
<whitequark>
cyborg_ar: i think glasgow should work fine on 7, if people so desire
<whitequark>
what i am *really* happy about is that no one, under no circumstances, ever, will ask me to support xp
<cyborg_ar>
lol
<whitequark>
because no usable python 3 release worked on it
<whitequark>
look.
<whitequark>
i have had incidents in the past.
<whitequark>
that involved windows xp.
<cyborg_ar>
but i want to run your thing inside my 20 year old oscilloscope!
<whitequark>
i doubt that actually runs xp
<cyborg_ar>
windows 2000 actually
<whitequark>
*facepalm*
<cyborg_ar>
hey the alternative is ME
<whitequark>
98se, no?
<d1b2>
<theorbtwo> I thought scopes were mostly wince.
<whitequark>
have people already stopped building firefox for that?
<whitequark>
or is that still ongoing?
<cyborg_ar>
i dont have the scope because i didnt win the auction, but the one im thinking about is the tek TDS5054
<whitequark>
theorbtwo: yet to see wince on a scope
<whitequark>
but lots of them are secretly PCs
<cyborg_ar>
windows 2000 "Open System(r)"
<whitequark>
or even not so secretly, just a mini-itx motherboard
<cyborg_ar>
yea
<d1b2>
<theorbtwo> I stand corrected.
<cyborg_ar>
original batch of 5054s came out with windows ME
<whitequark>
the silk implies it's a male IDC connector
<d1b2>
<Attie> uh, yep - it goes off to the side, with a ribbon in between
<d1b2>
<Attie> i wanted to put it on top originally, but i also had conflicting requirements (re connectors), so it now sits beside
<whitequark>
yep this makes more sense for a PCB this large i think
<whitequark>
can you send me one assembled one?
<d1b2>
<Attie> sure!
<whitequark>
same to esden for the eeprom thingy
<d1b2>
<Attie> i need to get parts in, and the stencil is... somewhere...? (perhaps in another package and delayed)
<whitequark>
i would also probably need a small car or something.
<whitequark>
:P
* whitequark
doesn't even have a drivers license
<d1b2>
<Attie> i was thinking of doing a HUB75 breakout, and probably a VGA breakout too, etc... just to fill in
<d1b2>
<Attie> hehe
<eddyb>
wow I woke up minutes before the delivery got here. also, somehow all the crap I got fit into a nice compact box
<d1b2>
<Attie> there are some industrial sensors that use CAN
<whitequark>
(can i pay someone with a crane to grab the nearest car wreck and deposit it somewhere near me? i guess not?..)
<gruetzkopf>
currently doing a board (eurocard) which uses both connectors (flip-board-glasgow on top)
<gruetzkopf>
(which also uses the TTL interop)
<whitequark>
nice
GNUmoon has quit [Remote host closed the connection]
<gruetzkopf>
i'd like to extend the LA applet with "put these pins in this state (statically)" - for use for example when you're sniffing something that needs an interface board in a certain state
<whitequark>
hm
<whitequark>
that doesn't seem super relevant for the LA applet, so i'm not sure how i feel about it
<whitequark>
on the other hand, it is useful functionality
<whitequark>
i think for now it makes more sense for you to have it out of tree, since pin management is kind of bad in general, but it is extra bad for the LA applet in particular
<whitequark>
and i don't want to merge an additional interface which will build upon the extra bad one to make it even worse
<whitequark>
(once out of tree applets are properly supported, we can yeet your thing into glasgow-contrib)
<gruetzkopf>
sounds reasonable
GNUmoon has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
egg|laptop|egg has quit [Read error: Connection reset by peer]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
egg|laptop|egg has joined #glasgow
<eddyb>
nice, PC buzzers. tho the beep code is kinda useless anyway
<eddyb>
I should try the grabbers but I don't think I've slept enough to be sure I won't just accidentally everything I touch
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
<agg>
whitequark: just fyi, the trailing {} in `pull_request: {}` isn't necessary, it means the same as having no value there
<agg>
what was fetch-depth:0 needed for?
<whitequark>
agg: that just makes it faster
<agg>
it makes it clone all history for all refs
<whitequark>
wait
<whitequark>
sorry
<agg>
by default it just clones the most recent commit
<whitequark>
it makes setuptools_scm work
<agg>
got it
<whitequark>
re trailing {}, i didn't know bare : would be valid yaml
<whitequark>
ecma-404 from 2017 does not include comments
<d1b2>
<DX-MON> hmm.. ok
<agg>
I want YAML-lite, I guess
<whitequark>
just ask tef :s
<whitequark>
about config formats
<agg>
maps, arrays, strings, numbers, bools, but no anchors, no guessing bools from 'yes' and 'true', idk... it's too cursed
<whitequark>
don't forget guessing times and dates
<d1b2>
<DX-MON> I want not-YAML for two reasons.. the spaces indentation (especially the choice of 2 only) seriously messes up my ability to read it.. and as it exists, it's a Turing complete programming language so not halting-safe and impossible to properly write secure parsers for
<agg>
2 only??
<agg>
YAML is like python, anything is a space if you squint
<d1b2>
<DX-MON> well.. those are the immediate two reasons that come to mind
<d1b2>
<DX-MON> you can't use tabs, and more than 2 spaces breaks many YAML parsers
<agg>
and you can use braces instead if you want, that's legit YAML too for some reason
<agg>
huh, really? i've never had issues with four-spaced YAML or braces
<agg>
I am willing to believe it
<agg>
the YAML spec says, and always has said, that indentation is zero or more space characters; in 1.0 it didn't allow tabs: "To maintain portability, YAML's tab policy is conservative; they shall not be used."
<d1b2>
<DX-MON> I think I understand the complaint of compliant JSON as not a config format thanks to that lack of comments (I think the verbosity with how that leads to unambiguity and so perfect machine parsability.. and with it having a schema system you can use.. is a "live with it") but at least it's capable of being a robust interop and data transfer format
<d1b2>
<DX-MON> I've yet to see a proof that TOML or so is really machine parsable
<agg>
sure, there are definitely use cases where json's shortcomings are less of a concern
<agg>
anyway I didn't mean to kick this off
<d1b2>
<DX-MON> XML SAX parsers and such are.. problematic.. because XML is provably not machine parsable, so I'm glad we don't consider it
<whitequark>
json is not capable of being a robust interop and data format.
<whitequark>
you can't even reliably transfer integers with it.
<whitequark>
this is something i hit /all the goddamn time/
<d1b2>
<DX-MON> even with a schema which is being strictly enforced?
<whitequark>
yes, if you have a 64-bit integer somewhere, half the parsers will do something useless
<d1b2>
<DX-MON> sure, I can believe that with my own work with the format
<d1b2>
<DX-MON> I have been
<whitequark>
the integer one is just particularly bad becaue it has bitten me ~every single time i worked on json stuff
<russss>
JSON but all values are strings (I think I actually did this once)
<whitequark>
it has bitten me in nextpnr, in ppx_deriving_json, and somewhere else
<agg>
I like msgpack for similar sorts of interop but it's frustrating that it got forked to cbor and now there are two almost-compatible standards
<whitequark>
in yosys in like two different places
<d1b2>
<DX-MON> some of those parsing problems go away if you ignore the later standardisations to be fair.. but I understand the frustration
<d1b2>
<DX-MON> msgpack got forked?
<russss>
oh no, it was JSON but all numeric types are parsed as Decimal - which does actually work relatively well.
<d1b2>
<DX-MON> I have to admit, I like the idea of msgpack.. I just don't like any of the impls out there
<whitequark>
dx-mon: the other issue with json is duplicate keys and keys being in different order
<d1b2>
<DX-MON> the APIs are.. not fun
<agg>
someone wanted it to be an RFC, so they wrote an RFC that was similar but different and called it something else and got it ratified, hence https://cbor.io/
<russss>
and iirc it's one argument tweak to `json.loads`
<whitequark>
like many other "simple" formats it is just not well defined enough to be parsable
<d1b2>
<DX-MON> thought JSON spec was clear that duplicate keys should be discarded as invalid on read
<d1b2>
<DX-MON> but fair
<d1b2>
<DX-MON> it's.. complicated.. designing something that's easy for a human to work with but which a machine can also unambiguiously parse is no mean feat
<whitequark>
DX-MON: The JSON syntax does not impose any restrictions on
<whitequark>
the strings used as names, does not require that name strings be unique, and does not assign any
<whitequark>
significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by
<whitequark>
JSON processors or in specifications defining specific uses of JSON for data interchange.
<whitequark>
so no, it is not defined by the spec AT ALL
<d1b2>
<DX-MON> mmm, ok
egg|laptop|egg has quit [Remote host closed the connection]
<d1b2>
<DX-MON> wrt that cbor thing, agg.. iew
<d1b2>
<DX-MON> what was wrong with ratifying what was already there darn it?! 😐
<d1b2>
<DX-MON> anyway.. ot, sorry
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
<eddyb>
well, the microscope works, but it's a bit overkill, and Discord won't let me see the unflipped video locally :/
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
egg|laptop|egg has joined #glasgow
<d1b2>
<Attie> just reading about the FX2 crossbar... this stuff is hairy, and things like this always makes me marvel at the fact that anything works at all
davidc__ has joined #glasgow
FFY00 has quit [Remote host closed the connection]
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
<d1b2>
<Grazfather> ooh congrats on this campaign! Just bought
egg|laptop|egg has joined #glasgow
<cyborg_ar>
looks like theres going to be a lot of glasgows
roxfan has joined #glasgow
<hell__>
Buuut... Will there ever be enough glasgows to cover the entire city of Glasgow?
* hell__
runs for cover
egg|laptop|egg_ has joined #glasgow
egg|laptop|egg_ has quit [Remote host closed the connection]
FFY00 has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
DarthCloud has quit [Ping timeout: 240 seconds]
nicoo has quit [Ping timeout: 240 seconds]
FFY00 has quit [Remote host closed the connection]
egg|laptop|egg_ has joined #glasgow
FFY00 has joined #glasgow
DarthCloud has joined #glasgow
nicoo has joined #glasgow
egg|laptop|egg_ has quit [Remote host closed the connection]
<eddyb>
Hack The Glasgow
<eddyb>
lost opportunity to get Limmy to announce the campaign going live, on stream,
<cyborg_ar>
i wonder if its gonna get 1000% funded
egg|laptop|egg_ has joined #glasgow
GNUmoon has quit [Ping timeout: 240 seconds]
egg|laptop|egg_ has quit [Remote host closed the connection]
egg|laptop|egg_ has joined #glasgow
elms has quit [Read error: Connection reset by peer]
elms has joined #glasgow
GNUmoon has joined #glasgow
egg|laptop|egg_ has quit [Remote host closed the connection]
egg|laptop|egg_ has joined #glasgow
egg|laptop|egg_ has quit [Remote host closed the connection]
egg|laptop|egg_ has joined #glasgow
bvernoux has quit [Read error: Connection reset by peer]
egg|laptop|egg_ has quit [Remote host closed the connection]
egg|laptop|egg_ has joined #glasgow
GNUmoon has quit [Remote host closed the connection]