DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<cyrozap>
cr1901_modern: Um, why on Earth would you want OpenOCD to contain an entire file-transfer client? Just SCP the file onto the box with OpenOCD as part of your Makefile (or equivalent), then either configure the telnet interface to listen on 0.0.0.0 (eww, insecure) or tunnel it via SSH/WireGuard/etc. and talk to OpenOCD from your local computer.
<cyrozap>
cr1901_modern: Usually, what I like to do is just write a "program the device" script for OpenOCD that gets SCP'd over along with the binary to program, then use SSH as part of my Makefile to run OpenOCD with the programming script. That way it's entirely automated and I don't even need to do any SSH tunneling/port forwarding.
DocScrutinizer05 has quit [Disconnected by services]
<kc8apf>
I started a quip about implementing protocol buffers for TCL but it seems people have actually done that to varying degrees
<cyrozap>
cr1901_modern: You could even split it up so it only transfers a file when it changes, and then "make flash" just runs the ssh command.
Dolu has quit [Ping timeout: 240 seconds]
<q3k>
i think it'd be nice for openocd to be a client/server design
<q3k>
so you could run the server wherver your jtag adapter is
<q3k>
and your client on your dev workstation
<kc8apf>
q3k: it is other than files needing to be local
<q3k>
the client would be interpreting scrips, loading files from your filesystems, opening gdb stub and console sockets
<q3k>
kc8apf: well, it's not really a client/server architecture, more that any client it communicates with just happens to be separated via a tcp/ip stack :)
<q3k>
it'd be nice if the entire jtag hal would be separated enough so it could be tunneled over gRPC onto an external machine without even thinking about it
<kc8apf>
it has a really terrible protcol between clients and server
<q3k>
you mean the text-oriented protocol into which one pipes 'reset ; halt' etc?
<kc8apf>
there's that which is a TCL interpreter
<q3k>
(haven't used openocd in a couple of years now...)
<kc8apf>
and a GDB server
<q3k>
oh god
<q3k>
why does every hw related product insist on being tcl scripted
<kc8apf>
I have no idea
<kc8apf>
I've learned that TCL has JSON and YAML libraries though
<q3k>
tcl has everything
<q3k>
i'
<q3k>
ve recently learned of the wish shell
<q3k>
and it still haunts me at night
<kc8apf>
Writing hw tools that _don't_ use TCL will almost certainly improve usability
<q3k>
eh, I generally don't hate on language choice
<q3k>
(unless we're talking about JS or PHP)
<q3k>
it's just that most of these tools that ship with tcl scripting don't usually come with any real documentation
<q3k>
so you end up reading horrible tcl code at 2am just to understand what the fuck is this weird function called by this scaffolded project code and that's never a fun thing
<q3k>
it seems like there's no such thing as non-write-only tcl in the hw vendor world
<kc8apf>
it's mostly chunks of code leftover from mergers that happened in the 80s and 90s
<kc8apf>
Vivado has a bunch of tcl scripts with copyright notices from Oasis and others
<q3k>
yeah
<q3k>
lattice diamond has 1990 copyright notices from NeoCAD :P
<q3k>
and then when you google for some of the .so files they use you find mostly info about xilinx tools
<q3k>
/\.n../ files in diamond are all heritage from neocad tools. and they're plenty of them
<kc8apf>
These tools being slow is a direct consequence of all these decisions: tcl, multiple acquisitions, et
<azonenberg_work>
q3k: this is what libjtaghal *does*
<azonenberg_work>
it provides abstraction at all levels
<azonenberg_work>
devices, adapters, etc
<q3k>
azonenberg_work: haven't heard of it
<q3k>
I'm not surprised there is such a project though, seems like a fairly low hanging fruit for anyone who know show software should be designed :P
<azonenberg_work>
q3k: azonenberg/jtaghal on github
<azonenberg_work>
i'm going to redo the TCP protocol to use protobufs instead of a home-baked protocol soon, but the C++ API will be the same
<q3k>
please use grpc :D
<q3k>
so I can call this from $favourite_language_of_the_week
<azonenberg_work>
I'd have to look into it, but plausibly
<azonenberg_work>
the thing holding me back previiously was that i wanted to make a hardware-accelerated JTAG module for starshipraider etc
<q3k>
it takes proto definitions of services (messages + rpc endpoints) and generates stubs for both server and client code
<azonenberg_work>
i.e. TCP direct to JTAG bypassing any CPUs etc
<q3k>
used internally at google for all services, so decently battle-tested
<azonenberg_work>
I'm going to have to reimplement it anyway
<azonenberg_work>
The thing holding me back from using protobuf was that there was no protobuf bindings for HDLs
<q3k>
i've seen your verilog protobuf thing and I'm still terrified by it :P
<azonenberg_work>
Lol why?
<azonenberg_work>
also, HTTP as transport
<azonenberg_work>
not sure if i'd do that
<sorear>
hopefully it doesn't require http/2
<azonenberg_work>
grpc does afaik
<azonenberg_work>
it would add a lot of complexity for low-latency embedded stuff
<q3k>
well, just that I'm mostly familiar with proto/grpc at a fairly high-level service abstraction level
<azonenberg_work>
My current plan is raw protobufs over TCP streams
<q3k>
seeing it being implemented in hardware is, uh, breaking my mind
<q3k>
i'm fairly sure you can take parts of the grpc spec and move it to another transport protocol
<azonenberg_work>
Perhaps
<azonenberg_work>
q3k: lol
<q3k>
it's just that it implements a lot of the wire protocols for serializing which method you're calling
<azonenberg_work>
Yeah makes sense
<azonenberg_work>
The way i've done this in the past was to have a single Message type
<sorear>
make sure it has some kind of authentication :p
<q3k>
and the method/service definitions are already part of the proto3 standard
<azonenberg_work>
that has a oneof{every type of message}
<q3k>
yeah, that's a decent enough approximation for it
<azonenberg_work>
Because i usually wanted low latency realtime communications
<azonenberg_work>
so i didnt want to add another protocol on top
<q3k>
but grpc dispatches but method name, not by parameter type
<azonenberg_work>
yeah thats the big difference
<azonenberg_work>
i didnt have any kind of RPC endpoints
<azonenberg_work>
this was a stream of messages going to one endpoint
<q3k>
also, grpc has a concept of streaming endpoints
<azonenberg_work>
sorear: The current jtaghal protocol does
<q3k>
as in methods that basically open a long living channel
<azonenberg_work>
Rather than try and homebrew something
<q3k>
where each side can throw messages reliably to ther other end
<azonenberg_work>
my plan is to tunnel it over SSP21
<awygle>
Doctors should not be allowed to use "crouton" as a descriptive metaphor for parts of my body.
<azonenberg_work>
(which i also need to make an FPGA implementation of soon, i've been talking to the devs about this for over a year)
<azonenberg_work>
awygle: um, do i want to know what part?
<azonenberg_work>
Something crunchy i assume?
<awygle>
azonenberg_work: foot bones
<awygle>
I prefer metaphors more in the "granite" family but apparently thats no longer accurate
<azonenberg_work>
oh fun... break something?
<q3k>
they could've went for something like cast iron if they were looking for hard but brittle... :P
<awygle>
Apparently we're up to seven fractures
<awygle>
Every time I talk to a doctor the number goes up
<azonenberg_work>
awygle: ouch, how'd you do THAT?
<azonenberg_work>
I have the opposite problem, apparently my bones are TOO strong
<azonenberg_work>
when i had my wisdom teeth pulled they had to yank so hard it almost dislocated my jaw
<awygle>
azonenberg_work: I pancaked my foot between a moped and a Mexican highway
<azonenberg_work>
been over a week and it still hurts to open more than halfway
<azonenberg_work>
Ouch, doesn't sound fun
<q3k>
awygle: ah yes, the classic mexican highway pancake maneouver.
<awygle>
Well it doesn't actually hurt. It's just.... Apparently going to take three months to "heal"
<q3k>
(ouch!)
<azonenberg_work>
awygle: Try softer highways next time
<q3k>
mid-foot fracture?
<awygle>
q3k: three metatarsals, two cuneiforms, one uh... Phalange I guess? And one "little one in the middle" which was the "crouton" comment
<q3k>
damn, ouch
<q3k>
i only sprained my midfoot (landed porly from a climbing wall, ugh) and it still was a pain to heal :(
<q3k>
just take it slowly for half a year and it'll be grand
<awygle>
whine whine complain whine....
<azonenberg_work>
lol
<Zorix>
i broke a toe last year walking really fast around a corner and forgetting i put a large lead acid battery on the floor and slammed right into it.. i saw stars heh
* implr
dropped a 1u server from ~1.5m on his foot once
<implr>
stopped hurting after about two days. probably should have gone to a doctor, but meeeeeh
<Zorix>
1u.. that can hurt.. im really careful around rack servers for that reason
<Zorix>
ive seen rails fail
<Zorix>
had this 10u beast one time that when we pulled it out for maintenance the ball bearings were falling out of the rail.. it never went in too well and had to stick a phone book between it and another server to keep it in there heh
<implr>
yeah, that was a failing rail, but it failed because I was an idiot and didn't install it properly
<Zorix>
hehe
<Zorix>
some are so dangerous
<Zorix>
like the ones where you have to extend it all the way out and locate like 4 pins whild putting it down onto it.. you need 2 people to do it
<gruetzkopf>
10U is either a bladecenter
<Zorix>
and sometimes you miss and nearly drop it
<gruetzkopf>
or big sgi stuff
<Zorix>
it was a giant sparc server
<gruetzkopf>
ooh nice
<Zorix>
might have been bigger than 10u too
<Zorix>
it was like 3 foot tall
<gruetzkopf>
i do have some SGI origin2000 and onyx2 at home
<gruetzkopf>
and i should have the cables and routers to build one box from the four soon
<Zorix>
good stuff
<q3k>
gruetzkopf: calling dibs for a shell on the origin :P
lb5tr has joined ##openfpga
<gruetzkopf>
when i can find several kilowatts of free electricity you might enjoy a 16-CPU 16-GiB-RAM n-TiB-FC-Storage irix box with 2 IR2E pipelines
<q3k>
mmm
<gruetzkopf>
someone *really* needs to look at NUMAlink and XIO
<q3k>
yeah, XIO is pretty neat from what I remember
<gruetzkopf>
i do have ideas about that
<q3k>
although I mostly looked at it on the octane
<gruetzkopf>
(looking for tg3 ethernet cards)
<q3k>
when I was young and naive and hoped to get a good linux port to it
<gruetzkopf>
octane and o2k xio are compatible electrically
<gruetzkopf>
if you make a card fit it works
<q3k>
now i just want an irix shell so i can finish my LPE exploit that I started working on on a friend's o2 :P
<q3k>
getting a cve for irix in 2018 is totally on my bucket list
<gruetzkopf>
ok then i'll run a single box without IR2E and one cpu card
<gruetzkopf>
i do have a mipspro license!
<q3k>
oh my
<q3k>
what is $(env cc) on IRIX, anyway?
<q3k>
mipspro?
<q3k>
or actually gcc?
<gruetzkopf>
i'm pretty sure i don't even have gcc on that box
<q3k>
also, writing an actually functioning emulator for an SGI box would be nice :(
<q3k>
need to get a O2 PROM dump and just start executing it
<q3k>
considering its' architecture is not fucking insance (ekhm it's not an octane), getting irix to boot shouldn't be _that_ difficult
<q3k>
s,octane,octane / origin,
<q3k>
*insane
<gruetzkopf>
yeah, serial port access is only possible after all the numalinks and xios are up
<gruetzkopf>
(stage 0x5b of bootrom)
<gruetzkopf>
(if anyone has a pci or pci-64 expansion enclosure+cable i'd want that)
<q3k>
what do you mean by expansion enclosure + cable?
<implr>
q3k: hum, what was that blue sgi box we had in hswaw, an o2? I remember it lying there fairly unused
<gruetzkopf>
it's XFP
<gruetzkopf>
installed modules are 10G shortrange, it's a very early 10G card
<gruetzkopf>
iirc they run 8*1.25G into the transceiver
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<cyrozap>
q3k, azonenberg_work: I kind of want to make OpenOCD more modular, but figuring out where to draw the boundaries of abstraction layers is *really hard*. Why? Because of the hardware vendors, of course. Every adapter protocol is home-grown, and sometimes it's tightly coupled to the target you're connecting to because the target has a weird timing-sensitive JTAG/SWD acquisition sequence
<cyrozap>
*cough*CYPRESS*cough*.
<azonenberg_work>
cyrozap: Thats the nice thing about something like jtaghal, though
<azonenberg_work>
You can do whatever you need in the target device class including sending raw scan commands to the adapter
<azonenberg_work>
I tried as hard as i could to avoid breaking the layering
<azonenberg_work>
And so far it seems i've succeeded
<azonenberg_work>
If you need tight timing i'd just say that a given device cant be used with the LAN protocol as that can introduce latency/jitter
<azonenberg_work>
Eventually i'd love to have something that exposes the ProgrammableDevice etc APIs over the LAN so you can do programming algorithm offload on the host rather than having the socket protocol only be raw scan commands
<azonenberg_work>
This would allow e.g. debug register polling to be much more performant because you arent pushing many Mbps of data over the network
<cyrozap>
And then vendors will make weird optimizations, so instead of giving you raw GPIO access to the JTAG/SWD pins or even just a JTAG state tracker, they'll only let you make raw reads/writes to the CoreSight DAP, so it only works with ARM devices and can't be used to program an FPGA.
<azonenberg_work>
over a VPN etc it's especially important to have any latency-critical stuff done on the host side
digshadow has quit [Ping timeout: 240 seconds]
<azonenberg_work>
yeah that is annoying
<azonenberg_work>
But this is why jtaghal has so many layers
<azonenberg_work>
So you can bolt stuff on at a higher level if needed
<azonenberg_work>
my (incomplete) jtaghal coresight stuff should work with an arbitrary transport without much refactoring
<azonenberg_work>
including a derived class in which "send this data to a MEM-AP" is a hardware call
<azonenberg_work>
Such optimizations make sense, in fact starshipraider will probably do some of them eventually, but they shouldn't be to the exclusion of basic jtag functionality
<cyrozap>
azonenberg_work: Try telling that to ST Micro and TI :P
<cyrozap>
(see: STLink and ICDI)
<azonenberg_work>
In all seriousness i would love to have more people hacking on jtaghal
<azonenberg_work>
right now it builds with Splash but i can probably hack up a parallel cmake build structure pretty quickly
<azonenberg_work>
I am trying to have it be a superior, cleanly architected alternative to openocd et al
<azonenberg_work>
(And permissively licensed)
<cyrozap>
Also, how do you handle adapters that support tracking breakpoints (etc.) in the adapter hardware (e.g., J-Link)?
<azonenberg_work>
So far, i dont have much on the debug side of things
<azonenberg_work>
it's mostly been for programming FPGAs
<azonenberg_work>
I'm in the process of bringing up MIPS debug support now for pic32
<azonenberg_work>
i have partial coresight stuff but nothing even remotely close to usable
<cyrozap>
The big problem is that vendors will continually break your assumptions about where you can make your abstraction boundaries, so you end up either not being able to support every adapter, or you make your system so modular the programming language you're using becomes the only layer of abstraction.
<cyrozap>
Also, that makes it really hard to define a language to do configuration because you can't assume users, many of whom are on Windows, to do a recompile every time they want to make a change to their adapter/target config. It results in the inner-platform effect (https://en.wikipedia.org/wiki/Inner-platform_effect), which often results in Turing-complete configuration languages.
<cyrozap>
Case in point: SDC config files, which are really just TCL plus a library to define all the SDC functions.
<cyrozap>
The obvious solution is to write your entire tool in a scripting language (ARM is trying to do that with pyOCD), but then you need your users to have a functioning environment to run those scripts in, which is really difficult on some platforms (e.g., Python on Windows). Oh, and because the tool is entirely script-based, it's one or more orders of magnitude slower than an equivalent tool written in a
<cyrozap>
compiled language.
digshadow has joined ##openfpga
<azonenberg_work>
cyrozap: i provide a C++ API and a command-line client providing a tiny subset of the supported functionality in the API
<azonenberg_work>
it's expected that to do anything unusual or complex you'd write code to poke the api directly
<azonenberg_work>
The high level API is... walk chain, get a ProgrammableDevice, call LoadFirmwareImage(), call Program() with the FirmwareImage object
<azonenberg_work>
That can be done entirely in the CLI
<cyrozap>
azonenberg_work: Regular users who can't recompile their tools have to do complex and "unusual" things surprisingly often. If you want to get them to use your tools, at some point you're going to have to make every piece of functionality scriptable in some way.
pie_ has joined ##openfpga
<azonenberg_work>
cyrozap: Because writing python is so much easier than writing C++?
<azonenberg_work>
and you wouldnt recompile the tool
<azonenberg_work>
you'd write a short application linking to the library
<azonenberg_work>
The primary deliverable of jtaghal is the API
<azonenberg_work>
the driver applications are just convenient shortcuts for super common things like flashing or erasing a target
<azonenberg_work>
(or running a gdbserver, once i implement one)
<azonenberg_work>
And they're a few dozen lines of code that just calls into the API
<cyrozap>
azonenberg_work: Yes, writing Python is 1000 times easier than C++, especially for embedded systems engineers who have only ever used C on microcontrollers. If your primary deliverable is an API, that's fine, but if you want more casual users you'll have to build a fully-featured frontend, which will include scripting in some form.
gnufan has quit [Ping timeout: 240 seconds]
gnufan has joined ##openfpga
Bike has quit [Quit: Lost terminal]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<azonenberg_work>
cyrozap: want to write one? :p
<azonenberg_work>
only half kidding
gnufan has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 256 seconds]
<cyrozap>
azonenberg_work: heh. OpenOCD currently meets my needs, so not really, but I don't think it'd be too difficult for you to add Python bindings to the API you export. I think they can be generated with SWIG, but I've never used it myself so I don't know how easy it is to use. If you do decide to do this, as an added bonus you could then replace your jtaghal command line interface with a standard Python
<cyrozap>
shell.
<cyrozap>
Actually, hmmm, that might not be a bad way to do things...
<cyrozap>
Put the high-performance stuff in C/C++, then chain actions together with Python.
<cyrozap>
Oh, wait, I think I just described GNU Radio...
<cyrozap>
Well, I guess that's a good example of a project that does that to great success.
<awygle>
Swig is really easy to do incredibly badly and quite difficult to do well
AlexDaniel has quit [Ping timeout: 248 seconds]
thallia has joined ##openfpga
nrossi has joined ##openfpga
<azonenberg>
lol
azonenberg_work has joined ##openfpga
Lord_Nightmare2 has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 260 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
rohitksingh-demo has quit [Quit: Leaving.]
AlexDaniel has joined ##openfpga
<azonenberg_work>
o_O xilinx seems to be fusing ultrascales
<azonenberg_work>
the xcku025, 035, 040 are all the same bitstream size
<azonenberg_work>
as are the vu080/vu095 and vu160/vu190
<rqou>
why are you looking into this?
<azonenberg_work>
i assumed that the large parts wouldnt be fused as the fab cost would be so high
<azonenberg_work>
Just skimming the ultrascale config guide using about my future switch project
<rqou>
ah
<azonenberg_work>
The ku035 is supported by webpack
<azonenberg_work>
As are some of the smaller ultrascale+ kintexes however those seem to be overkill
<azonenberg_work>
the big advantage is higher GTP speed
<azonenberg_work>
And the normal ku can do 10G
<azonenberg_work>
ku+ can do faster but that buys me nothing for ethernet
<azonenberg_work>
and i think ku is still fast enough to do 10G line rate switching no problem
<azonenberg_work>
Anyway, my first version will still be artix based
<eduardo_>
rqou: Whats the webadress of your web hosted ice40 bitstream generator?
<eduardo_>
rqou: we are in discussion with them to do a ICE40 Badge :-)
<eduardo_>
rqou: They have some concerns of how accessible and hackable the badge would be for not-so-smart-attendees
<eduardo_>
rqou: a badge firmware which would load bitstreams from a webpage would be an easy thing.
<eduardo_>
rqou: and the webpage could generate bitstreams on demand
<rqou>
are you sure it would be easy? that page i built runs _in your browser_ client-side
<rqou>
it's not compiled on the server
<rqou>
so you need a computer
<eduardo_>
rqou: you would need a computer anyway to connect the badge over USB to the internet.
<rqou>
well, i guess i really should clean it up then :P
<eduardo_>
rqou: I need to see if Hackaday is interested in the concept, and if we make budget and find someone to manufacture the badge.
<pie_>
cool
Dolu has joined ##openfpga
eduardo_ has quit [Read error: Connection reset by peer]
eduardo_ has joined ##openfpga
ondrej2 has quit [Read error: Connection reset by peer]
plaes has quit [Ping timeout: 255 seconds]
plaes has joined ##openfpga
uovo has joined ##openfpga
oeuf has quit [Ping timeout: 260 seconds]
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 240 seconds]
ondrej2 has joined ##openfpga
m_t has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
Dolu has quit [Ping timeout: 268 seconds]
AlexDaniel has quit [Ping timeout: 265 seconds]
pie_ has joined ##openfpga
Dolu has joined ##openfpga
AlexDaniel has joined ##openfpga
<cr1901_modern>
cyrozap: then either configure the telnet interface to listen on 0.0.0.0 (eww, insecure) <-- Because I haven't figured out how to do that
<cr1901_modern>
If it's in the manual, it's well hidden
<cr1901_modern>
cyrozap: Also, it's the other way around. Vivado is on the remote. My board is attached to my local machine. My local machine runs windoze. Getting scp to work is more trouble than it's worth.
<cr1901_modern>
And even if I could telnet into my local machine, I'd still have to manually type the commands (though I guess I could use expect for this)
<cr1901_modern>
Yes, writing Python is 1000 times easier than C++ <-- this holds true in my experience, and C++ was the first language I ever learned*.
<cr1901_modern>
*Badly, from an outdated book that still used <iostream.h>.
<cr1901_modern>
It is easy to create a dozen-line C++ code snippet, without trying, that I couldn't tell you what it does. At least w/ C/Python IME, you have to deliberately try to confuse me.
wolfspraul has joined ##openfpga
Dolu has quit [Ping timeout: 248 seconds]
Dolu has joined ##openfpga
<anuejn>
you could use webmidi to upload new code via usb to the badge
<anuejn>
by crosscompiling yosys and archanepnr with emscripten, we could build an entirely web based playground
<anuejn>
uh failed to read the backlog, sorry
pie_ has quit [Ping timeout: 256 seconds]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
digshadow has quit [Ping timeout: 246 seconds]
<rqou>
anuejn: webmidi is still chrome-only for now
<rqou>
trust me, I've looked into this
<sorear>
why midi?
<rqou>
AFAIK the only current way to get data from the browser to a hardware device right now in a cross-browser and cross-platform way is to pretend to be CDC-ECM+RNDIS and put websockets on top
<jn>
or encode stuff in audio ;)
<rqou>
sorear: because midi is one of the bidirectional "access hardware" protocols that the "web infosec cabal" hasn't understood the implications of and therefore are least likely to complain about
<jn>
(like chibitronics does, AFAIK)
<rqou>
unlike e.g. webusb where the chrome team basically gave up and said "ok, just pop up another security toaster"
<jn>
(it's been described in a talk by bunnie)
<rqou>
yes, that's another way
<rqou>
it's not clearly easier that cdc-ecm+rndis
azonenberg_work has quit [Ping timeout: 265 seconds]
<jn>
especially if you want to transfer any significant amount of data
<rqou>
sorear: afaict the "web infosec cabal" hasn't yet realized that midi is more than "i banged on a keyboard/drums and some packets came out" and actually allows tunneling arbitrary data over it (including synth firmware upgrades)
<jn>
practical MIDI security is probably rather horrid
<jn>
once you connect The Web
<rqou>
or if you're a weeb, reinventing midi by storing notes in an ini and hiding this ini in a giant sysreq
<rqou>
jn: but afaict nobody important has noticed that yet
<sorear>
remember when the first-gen Apple iSight was a USB device that could be accessed from userspace, reflashed from userspace, and turned into a keyboard
<jn>
rqou: send taviso a keyboard ;)
<rqou>
no, i _want_ "poke hardware from js" APIs, and i want them to add the APIs _first_ so that they end up with enough power
<rqou>
they'll retcon security back in eventually
digshadow has joined ##openfpga
<sorear>
I saw a device N years ago that took data from a computer at a few bits/s using a photocell and a program that rapidly flashed the screen
<rqou>
electric imp?
<rqou>
yeah, but that's slow
<sorear>
it was a very early smartwatch
<rqou>
i still think cdc-ecm+rndis/websockets is better
<rqou>
plus it works today
<rqou>
also, webmidi is nice because afaik it doesn't have a security toaster because they haven't realized they need it yet
user10032 has joined ##openfpga
<rqou>
oh dang, there is a security toaster for webmidi now
<rqou>
it used to only have a toaster when using sysex
<sorear>
they might be taking it more seriously because they found an rce/sandbox escape in the webmidi stack
<cyrozap>
cr1901_modern: If your local machine is on Windows, run an FTP server (or Samba/CIFS or whatever) on the Vivado system and mount that from within Windows (I think it's called "Map a network drive"). Then you should be able to program the board by pointing OpenOCD to the file on the mounted drive.
<cyrozap>
cr1901_modern: Regardless, network file transfer is _way_ out of scope for the OpenOCD project.
<cr1901_modern>
Yes I could do that too
mumptai has quit [Quit: Verlassend]
user10032 has quit [Quit: Leaving]
Bike has joined ##openfpga
inode has quit [Quit: ]
<kc8apf>
I'm going to have a working continuous integration system for Vivado pretty soon. Happy to help anyone else who wants to do something similar.