<rqou>
alright, does anybody know how to actually obtain libudev?
<rqou>
somehow all i can find is that somehow it's part of systemd now?
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<rqou>
arrgh i f*cking hate cmake
<rqou>
the library is _right there_
<rqou>
you even printed that you found it
<rqou>
and yet you complain that it's not found
lexano_ is now known as lexano
<azonenberg>
rqou: soo re the coolrunners
<rqou>
i have literally never had cmake reduce the number of problems i have
<azonenberg>
They are definitely laser marked
<azonenberg>
The font width is slightly different on the two
<azonenberg>
between the two*
<azonenberg>
One of them has flux residue on underside
<rqou>
whelp
<azonenberg>
There is a ground pour on the bottom that i was going to compare to the actual coolrunner bondout
<azonenberg>
I suspect they're pulls at best, possible full fakes
<azonenberg>
But we'll find out
<rqou>
oh they're almost certainly pulls
<rqou>
hence why i wanted you to try to extract bitstreams from them
<rqou>
but if you suspect it's remarked, that's interesting
<rqou>
ohh
<rqou>
azonenberg: i bet the speed grade is remarked
<azonenberg>
So the big thing i noticed is
<azonenberg>
the toolpath the laser took for the xilinx "X" logo
<azonenberg>
was not the same on both chips
<azonenberg>
one was raster and the other was more of a swirly vector
<rqou>
for the 512 or the 384?
<azonenberg>
One vs the othert
<rqou>
i did notice that the color of the substrate was different for 1 of the 4 chips
<azonenberg>
both of the same SKU were the same pattern
<azonenberg>
That was flux residue
<azonenberg>
I'll take a closer look later, have to clean a bunch of my sar stuff and refill before the next call
<rqou>
woo finally
<rqou>
$ ldd ./iceprog/iceprog
<rqou>
not a dynamic executable
<rqou>
there we go
<rqou>
aargh except icestorm strips CFLAGS
<pie__>
whats SAR?
<pie__>
rqou, pulling bitstreams is so much cooler than buying off ebay
<pie__>
*buying used HDDs off ebay
<azonenberg>
pie__: search and rescue
<pie__>
ah
<pie__>
got it
<pie__>
is it bad that i thought data recovery for a second
<rqou>
azonenberg: at least make an attempt to retrieve the bitstream before destroying it? :P
<rqou>
woot
<rqou>
$ file iceprog
<rqou>
iceprog: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
<rqou>
no qemu-user-static required this time
<rqou>
ugh, i have to touch the "hostile takeover" project again
<rqou>
aaargh pkg-config is yet another "doesn't solve any problems" tool
digshadow has quit [Ping timeout: 260 seconds]
<awygle>
rqou: maybe your problems just aren't the ones it's solving?
<balrog>
rqou: what's the problem you're trying to solve?
<rqou>
"find my library file that i built for the target architecture"
<rqou>
without me needing to go in and patch .pc files
<balrog>
You need it to be architecture specific?
<balrog>
Meaning you're doing multiple architectures?
<rqou>
um, yeah?
<rqou>
i'm trying to kill "needs a whole friggin container with qemu-user-static"
<balrog>
Most people do that with custom prefixes. Or use cmake.
<rqou>
cmake also adds problems rather than solving them
<rqou>
and i already have a custom prefix
<balrog>
I don't think pkgconfig was designed for that use case
<rqou>
it actually seems to be working for arm-linux
<rqou>
mingw is broken though
<balrog>
I've generally found it easier to beat a cmake based workflow into submission than an autotools one
<rqou>
quite possibly because mingw has its own set of gratuitous brokenness
<balrog>
mingw is broken? News at 11
<rqou>
i've generally found the opposite
<rqou>
i hate cmake workflows
<balrog>
It took me a bit to get used to them but they are generally more straightforward and flexible
<rqou>
well, earlier cmake was telling me it couldn't find a library that it _printed out as found_
<rqou>
which is pretty brilliant
<rqou>
azonenberg: when is splash going to be done? :P
<balrog>
Probably a broken custom library-find script
<rqou>
somehow cmake users seem so love turning build systems into "find all your shit" systems
<rqou>
which is what i specifically _don't_ want
<rqou>
especially since half of the "find all your shit" systems return the wrong answer half the time
<awygle>
cmake is a special kind of hell
<rqou>
i don't understand why "traverse a DAG" is so hard
<rqou>
for bonus points, cmake can't actually traverse a DAG
<rqou>
it has to fall back on make to do that part
<awygle>
somebody on the #gcc channel recently said something like "every time somebody starts a new project with make, you're a little sad, but you can't actually recommend anything better"
<awygle>
i mean traversing the DAG is the easy part. surely the hard part is building it
<balrog>
cmake still uses make
<balrog>
(Or ninja or something else)
<rqou>
exactly why it's silly
<awygle>
yes yes. the sentiment was comedic rather than literal.
<awygle>
several of my friends swear by scons
<rqou>
i tried using waf for a project
<rqou>
i hated it because despite selling itself as "just traverses a DAG, correctly" waf is very "opinionated"
<awygle>
i worked with a guy at berkeley who went by waf... always wonder if he's responsible for the build system.
<rqou>
i've been meaning to write a "JustADAGDammit" build system but never got around to it
<rqou>
azonenberg's splash might be something like that
<balrog>
I got turned away from scone because it has awful support for multiple architecture projects
<balrog>
cmake does better there
<rqou>
hmm, in my experience cmake is just as bad as everything else
<rqou>
sure, it has an idea about "toolchains"
<rqou>
and then somehow somebody will manage to hardcode in a /usr/lib anyways
<rqou>
wtf my entire gui stack just crashed for some reason
<azonenberg>
splash is basically a dag build system, yes
<azonenberg>
plus caching and parallelism
<azonenberg>
But building build dags right is hard :p
<azonenberg>
almost all of the bugs i currently have / had in the past were related to incorrectly building the dag
<whitequark>
awygle: *definitely* get your cats toy mechanisms
<awygle>
whitequark: will do. i am now intensely curious about my old cat's behavior of fetching a mouse only 50% of the way back to me...
rk[ghost] has quit [Ping timeout: 276 seconds]
rk[ghost] has joined ##openfpga
<whitequark>
yes.
<whitequark>
we cooperate in catching moths.
<whitequark>
i can reach the ceiling, but the cat has *far* lower reaction time
<whitequark>
these goddamn moths are so fast I can't even turn my eyes quickly enough to track their movement
<whitequark>
the cat though, the cat could be ground support for a guided missile
<whitequark>
which, incidentally, gives me an idea
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
<azonenberg_work>
rqou: so, coolrunner update
<azonenberg_work>
They might actually be legit xilinx devices (though possibly upmarked)
<azonenberg_work>
the ground/vccio pad layout in the middle of the die looks exactly like the real xilinx ftg256
<azonenberg_work>
Speed grades marked are -6 and -10 for the 384 and 512 respectively
<azonenberg_work>
The 384 is actually offered in -7, -10
<azonenberg_work>
as is the 512
<azonenberg_work>
one of the 512s has pieces of solder braid and dust stuck to flux on the underside
Hootch_Work has joined ##openfpga
digshadow has joined ##openfpga
<cyrozap>
Fun fact: The Cypress MiniProg3 uses an FX2LP, a PSoC 1 (!), _and_ an XC3S100E (!!!).
* cyrozap
has been doing some MiniProg3 RE
<cyrozap>
The FX2LP seems to load its firmware automatically at boot, so the only code that needs to be uploaded is the Spartan-3E bitstream. Thankfully, it's pretty much just shoveling the binary over USB, so that's nbd.
<cyrozap>
Also, the SWD protocol it uses looks pretty much the same as the one used on the KitProg ("mild shock"), so I'll probably be able to share some code with the OpenOCD KitProg driver.
<rqou>
azonenberg_work: while i'm cleaning up build system stuff, please please test the no-udev PR
qu1j0t3 has quit [Ping timeout: 248 seconds]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
indy has joined ##openfpga
<rqou>
it's so weird testing cross-compiling when you have qemu-user-static installed
digshadow has quit [Ping timeout: 240 seconds]
qu1j0t3 has joined ##openfpga
<rqou>
fun fact: gp4prog built for arm works under qemu-user-static while iceprog built for arm doesn't
<rqou>
(er, with my no-udev PR at least)
Hootch_Work has quit [Quit: Leaving]
indy has quit [Ping timeout: 240 seconds]
indy has joined ##openfpga
indy has quit [Ping timeout: 240 seconds]
indy has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
pie__ has quit [Remote host closed the connection]
<jeandet>
Hello I would like to try adding VHDL and later Verilog support in meson build, anyone interested?
<jeandet>
The idea would be to integrate toolchains such as Vendor ones or GHDL, Icarus.. in meson and being able to create/maintain projects easily.
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
m_w has joined ##openfpga
<pointfree>
cyrozap: I used one of these https://sigrok.org/wiki/Lcsoft_Mini_Board to program PSoC 5LP's before you, et al, had implemented openocd support for the KitProg.
<pointfree>
It's interesting to hear what's inside the FX2LP.
<balrog>
pointfree: it makes sense that Cypress used things from the FX2 in their later chips
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
digshadow has joined ##openfpga
amclain has joined ##openfpga
<cyrozap>
balrog, pointfree: To clarify, there isn't a PSoC 1 inside the FX2LP, and there isn't a PSoC 1 inside the FX2LP--they're separate chips. Also, by "load at boot", I meant it has the firmware stored internally and loads that on every boot--as opposed to loading it over USB on every boot.
<azonenberg>
rqou: i'll test it when i have time, i'm kinda in the middle of stuff now
<jeandet>
cyrozap, thank you, I already know this project, I think they implemented their own system in Python. What I propose is to use an existing build system and add FPGA related features. My goal is to also rely on meson features such as wrapdb, transparent test wrapping, use of ninja and really simple syntax(Not Turing complete).
<jeandet>
The other cool stuff would be to be able to mix RTL code and SW for soc projects with the same build system.
<balrog>
cyrozap: I'm aware — what I meant is that sharing design patterns in newer devices does not surprise me
<balrog>
jeandet: if you don't mind poking your head into Verilog, you could do a full open-source iCE40 workflow
<jeandet>
This a draft of what it may look like. Any comment or help are welcome!
<jeandet>
balrog, Yeah but I'm French... I've never used Verilog :(
<balrog>
unfortunately I'm not aware of any system that can turn VHDL into something that the existing place-and-route tools handle. There have been some attempts to add VHDL support to yosys but none have gone sufficiently far...
<balrog>
I think rqou was working on one and then kinda got lost with the complexity :)
<jeandet>
There is a tool that convert all the VHDL sources in one Verilog file, one of my colleague tried it, I don't know if it works well...
<balrog>
a tool like that might work at the netlist level
<balrog>
probably not so well at higher levels
<jeandet>
Anyway in a first time, we can support fully free simulation workflow, then for implementation we have to use Vendor tools until situation gets better.
<balrog>
though yosys has its own intermediary-language formats...
<balrog>
what I'm saying is that if you want to try to support a fully free workflow including implementation, you could do so with yosys and arachne-pnr and icestorm
<balrog>
but you'd be stuck with verilog for now
<balrog>
if you have a way to generate a BLIF format technology-mapped netlist from VHDL, you could do that too
<jeandet>
In fact I mainly what to bring attention to standard build systems like Meson and start a basic implementation to support FPGA workflows.
pie__ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
<jeandet>
As a GRLIB user, I kind of like their script until I have to read them and worse to edit them.
<jeandet>
Their usage of Makefiles is insane
<jeandet>
My feeling is that their is many aspects in common between FPGA flow and Software building. Such as dependency tracking, Unit testing and just compiling files.
digshadow has joined ##openfpga
pointfree[m] has quit [Ping timeout: 240 seconds]
enick_88 has quit [Ping timeout: 258 seconds]
<pie_>
well maybe people try to make fpga flow more like software dev