jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #glasgow
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
IanMalcolm has quit [Ping timeout: 252 seconds]
jevinskie has joined #glasgow
IanMalcolm has joined #glasgow
m4ssi has joined #glasgow
Jasjar_ is now known as Jasjar
ender| has quit [Ping timeout: 258 seconds]
pie___ has quit [Ping timeout: 258 seconds]
puck has quit [Quit: nya]
puck has joined #glasgow
<whitequark>
electronic_eel: that's definitely one option
<whitequark>
but here's the thing
<whitequark>
redistributing the glasgow stack is a royal pain in the ass
<whitequark>
(primarily on windows)
<whitequark>
so a mode where the python, yosys, nextpnr aren't involved definitely has a lot of value
<whitequark>
for example i was thinking about making it possible to use glasgow with linuxcnc, as a "remote hal"
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<electronic_eel>
hmm, but isn't having glasgow hw, but without any of the software, a bit out of scope? i think the software stack is a major part and someone who want's to use glasgow should do the work required to install the software somewhere
<electronic_eel>
we could use a socket bouncer like socat to allow having the full software stack somewhere else
<electronic_eel>
then you could run the software in a vm or don't have to install it on your deeply embedded cnc controller
<whitequark>
electronic_eel: yes, you need software somewhere
<whitequark>
but socket bouncing just doesn't work
<whitequark>
awful design with way too many moving parts
<whitequark>
instead of serializing the necessary information and storing it together with what actually does the job (in bitstream or in the fx2) you now require some kind of RPC mechanism, port forwards, port assignments, running a server...
<whitequark>
instead of being able to turn on your CNC controller and have it work right away, you need to have another machine running somewhere that's accessible during startup
<whitequark>
just no
<whitequark>
that's not to say that the socket approach is *never* useful. i think for example to work with sigrok it's pretty much the only reasonable choice
<whitequark>
unless you can build a good clock mux in fabric which i doubt
<electronic_eel>
i think it is very awkward to plug glasgow into one system, upload a bitstream to flash, plug it in another machine, use it a bit, find that you need to change some setting and do the whole thing again
<electronic_eel>
if we don't want to require installing the software stack i think some networking, rpc,... mechanism is the best choice
<electronic_eel>
maybe not use some preexisting software like socat, but build a minimal glasgow server program which does all that is needed
<electronic_eel>
would be designed to require minimal external dependencies
<electronic_eel>
could be packaged as msi for windows
<whitequark>
11:21 <@whitequark> instead of being able to turn on your CNC controller and have it work right away, you need to have another machine running somewhere that's accessible during startup
<electronic_eel>
is that really that much of a pain? i have like 4 or 5 machines running all the time
<whitequark>
i don't
<electronic_eel>
and for your cnc controller you probably want some cam software or cad program to control it
<whitequark>
so? that doesn't justify adding startup sequencing requirements
<whitequark>
networks are fundamentally flaky
<electronic_eel>
not much worse than usb...
<whitequark>
one example of using glasgow without any of its software stack anywhere is the gameboy rgb capture applet i made
<whitequark>
it only interacts with a rust program that's fetching frames
<whitequark>
this use case is completely impossible with a socket or whatever
<whitequark>
because it can't be deployed
<electronic_eel>
i haven't seen the applet and don't understand what it is doing yet
<whitequark>
captures frames from the gameboy rgb555 bus
<whitequark>
video-rgb-input applet
<electronic_eel>
and why can't you use it with a socket?
<whitequark>
because the way you use it is you plug in the device, run the grabber (a single .exe), done
<electronic_eel>
and why can't the grabber exe first connect to the socket, set up the bitstream and then do it's thing?
<whitequark>
because there's no yosys or nextpnr or glasgow or python anywhere on the target machine
<whitequark>
and there shouldn't be, because rebuilding the exact same bitstream over and over is pointless
<electronic_eel>
understood. but that's what the socket bouncer could help with
<whitequark>
what socket bouncer?
<whitequark>
i ship the whole contraption to somewhere on the other side of the planet
<whitequark>
what do you suggest, me running a web service for them 24/7 just because you don't want to store some metadata in BRAM?
<electronic_eel>
ah, ok, i thought you run it on one of your other machines
<electronic_eel>
didn't think about shipping it to someone else
<whitequark>
any suggestion that involves replacing "storing 1k of data on the device" with "running a complicated network service with rpc" is preposterous
<whitequark>
why is this even a discussion?
<electronic_eel>
i primarily thoug
<electronic_eel>
thought about always changing configs
<electronic_eel>
not about running the same bitstream for a long time
<whitequark>
ok, fair
<whitequark>
to be clear
<whitequark>
11:26 < electronic_eel> maybe not use some preexisting software like socat, but build a minimal glasgow server program which does all that is needed
<whitequark>
this does make sense on its own
<whitequark>
but for other cases
<whitequark>
like someone asking me to take a look on a DUT they have connected
<electronic_eel>
yes that would be really handy for remote debugging too
<whitequark>
exactly
<whitequark>
i think it should exist
<whitequark>
i might prototype the protocol soon-ish
<whitequark>
the final version of the server would probably be in rust
<electronic_eel>
and i think it might also make sense for cases when installing t
<whitequark>
i'm not sure which level it makes sense to expose it at
<electronic_eel>
the software stack on some other local machine
<whitequark>
like should it be libusb level or should it be something higher
<electronic_eel>
because of packaging or similar
<whitequark>
libusb level: simple
<whitequark>
higher level: allows using a sensible protocol that potentially can carry over to revE
<electronic_eel>
do we need low latency for this to work?
<whitequark>
no
<whitequark>
not really
<electronic_eel>
openocd for example would run on the same machine glasgow hw is connected to, just the glasgow software is running somewhere else
<electronic_eel>
so low latency isn't an issue there too
<whitequark>
it is
<whitequark>
not because it wouldn't work but because high latency jtag just sucks
<whitequark>
this is why i think glasgow should directly implement all common debugging targets
<whitequark>
ideally e.g. MIPS EJTAG PrAcc would run completely on gateware
<whitequark>
you can't really integrate that with openocd
<electronic_eel>
but wouldn't openocd directly talk to the locally connected glasgow?
<electronic_eel>
i mean hw
<electronic_eel>
to the gateware handling the jtag innards
<whitequark>
no, i don't see how that would work
<whitequark>
the glasgow server only does one thing: allows accessing hardware over network
<electronic_eel>
the glasgow network daemon tells the openocd driver the usb ids
<whitequark>
that's another flaky overcomplicated design
<whitequark>
no
<whitequark>
running three network daemons to debug some chip is not acceptable
<tnt>
I'm wondering if doing it like the BMP would be doable ... put a gdb srver ina riscv inside the fpga and just channel things through a cdc serial port.
<whitequark>
besides that, i don't think you can even do that on windows
<whitequark>
because you can't claim interfaces separately
<whitequark>
without a composite driver
<whitequark>
tnt: sort of
<whitequark>
but i am generally opposed to adding more microcontrollers on glasgow if at all possible
<electronic_eel>
urgh, windows driver model sucks
<whitequark>
windows driver model sucks a lot
<whitequark>
unfortunately that's also where our worst cases for software are
<whitequark>
because on linux i can simply prepare a statically linked complete toolchain runnable out of a tarball unpacked anywhere
<whitequark>
it's not ideal but it's a fallback that's always available
<electronic_eel>
you could package a whole python and so on for windows too
<electronic_eel>
is just a lot of dirty work
<whitequark>
key word "simply"
<whitequark>
it is not simple on windows
<whitequark>
what i want is basically... conda
<whitequark>
but conda doesn't work so i can't use it
<electronic_eel>
nothing is simple on windows
<whitequark>
nah, solvespace is simplest to use on windows
<whitequark>
because it's one .exe, and the linux and macos situations are a nightmare
<electronic_eel>
gl driver things?
<whitequark>
nope
<whitequark>
just that they have a lot more moving parts
<whitequark>
gl is actually the worst on windows, because i had to resort to ANGLE
<electronic_eel>
regular lib dependency and distro incompatibility takes some time but i think it is manageble
<electronic_eel>
gl driver stuff would be something i'd really hate to fix
<whitequark>
that's not what happens in practice
<whitequark>
in practice what happens is people are running solvespace.exe in wine
<whitequark>
because linux is a nightmare
<whitequark>
macos, well, macos is fucked, but everyone who still uses macos is used to that, so they either cope or stay silent
<electronic_eel>
i always wonder why people still use macos. apple breaks it every release and blocks people from downgrading
<electronic_eel>
that is just evil
<whitequark>
there are tools that only really exist for macos
<electronic_eel>
weren't there some efforts to virtualize macos in quemu/kvm, with some hacks to make it think it runs on a proper apple hw?
<whitequark>
yes, i used that until about 10.10
<whitequark>
after 10.10 i was never able to get it to work
<electronic_eel>
that would be my first try if i'd rely on some mac sw
<whitequark>
it was never actually usable.
<whitequark>
you only had a software renderer
<whitequark>
i used it as a build machine for solvespace over ss
<whitequark>
*ssh
<electronic_eel>
ah, ok gl stuff again. i know why i don't like it
<whitequark>
opengl is awful and no thought went into its design
<whitequark>
the problem is that opengl successors are also awful and no thought went into their design with respect to migrating from opengl
<whitequark>
moltengl is something that apple should have provided free of charge
<thaytan>
except that their goal was pretty clearly to make people to migrate to Metal, so they'd be more locked in
<thaytan>
"have to"
<thaytan>
banking on iOS being a big enough platform
<thaytan>
sociopaths gonna sociopath
<thaytan>
whitequark, I got as far as compiling solvespace in xcode, but then it looked like you were getting much more knowledgeable help from troughton on https://github.com/solvespace/solvespace/issues/354
<whitequark>
it's pretty funny how people hate on apple but no one else can make a remotely secure architecture
<thaytan>
in a laugh or cry way
<whitequark>
i think 90% of apple hate is stupid
<whitequark>
and i would essentially never use an apple product, for that matter
<thaytan>
I find it infuriating that they are so popular (and expensive), when every experience as a cross-platform developer is a nightmare
<thaytan>
or even trying to do things "the Apple way" without trying to keep cross-platform is a relentless game chasing their deprecations and breakages
<whitequark>
that's somewhat of a failure, yes
<whitequark>
modern windows is the same (look at uwp)
<whitequark>
and... modern linux is partly the same (systemd and whatnot) and partly a pile of unusable garbage from the 70s
<whitequark>
so it really just comes down to the poison you pick
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<thaytan>
*nod*
carl0s has joined #glasgow
ender| has joined #glasgow
puck has quit [Remote host closed the connection]
puck has joined #glasgow
ender| has quit [Ping timeout: 276 seconds]
m4ssi has quit [Remote host closed the connection]
ender| has joined #glasgow
ender| has quit [Ping timeout: 258 seconds]
carl0s has quit [Quit: Page closed]
ender| has joined #glasgow
carl0s has joined #glasgow
carl0s has quit [Client Quit]
puck has quit [Quit: nya]
puck has joined #glasgow
jevinskie has joined #glasgow
jevinskie has quit [Client Quit]
puck has quit [Quit: nya]
puck has joined #glasgow
ender| has quit [Ping timeout: 276 seconds]
ender| has joined #glasgow
steve|m_ is now known as steve|m
jevinskie has joined #glasgow
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #glasgow
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]