<whitequark>
soooo.... you can do a relational dependency on the version in conda, but not build numebr
<whitequark>
and conda won't look into the repository if a local package exists
<whitequark>
so, either you waste a lot of time downloading everything over and over, or you waste slightly less time updating the exact dependencies every time you bump a build number for fixing a bug, or you manage its cache manually
<whitequark>
such a great design
<whitequark>
bb-m-labs: force build --props=package=rust-core-or1k conda-lin64
<bb-m-labs>
build forced [ETA 44m39s]
<bb-m-labs>
I'll give a shout when the build finishes
mumptai has quit [Remote host closed the connection]
key2 has joined #m-labs
key2 has quit [Ping timeout: 264 seconds]
key2 has joined #m-labs
<whitequark>
so is there a working gdb for or1k?
<whitequark>
or is that a trash fire too?
<whitequark>
so far I see that it was ripped out of 7.11 or something earlier, but no version where it actually works, including the one the wiki claims does
<whitequark>
ok, so there's broken upstream support, and their fork, and the wiki just lies
<whitequark>
at least their fork seems to function
<rjo>
whitequark: nice!
<whitequark>
also I accidentally added debugging support
<whitequark>
to the core device
<whitequark>
well, sort of. it is more like core dumps, except nothing is dumped anywhere
<rjo>
sb0: yes. that latency adjustment pattern needs to work just as well for dds/spi/pdq. (multiple) derived classes looks good to me.
<rjo>
whitequark: ha. no blue screen?
<whitequark>
rjo: no, I mean you can connect with gdb and introspect the death state
<whitequark>
I got way too annoyed deciphering bluescreens by hand
<whitequark>
it is probably not too hard to add actual debugging as well
<whitequark>
rjo: yep that works
<whitequark>
build or1k-elf-gdb (specifically for --target=or1k-elf; other targets don't build) and then
<whitequark>
I know a good idiomatic expression to describe a setup with this amount of indirection, but it is too obscene to cite
sb0 has joined #m-labs
<sb0>
kcu105 is up and connected to the buildserver
<sb0>
haven't looked into programming it yet
<whitequark>
sb0: can we raise the UART speed on the SoC by a factor of, say, 10?
<sb0>
maybe
<sb0>
try it...
<sb0>
so the buildserver now has two KC705s, a KCU105 and a pipistrello
<rjo>
yay.
<sb0>
they've put a Zynq on the KCU105, in addition to the KU. they really want to sell that stuff...
<larsc>
sb0: wait until you know what it's function is
<larsc>
it is the power-management chip
<larsc>
putting the right voltages on the FMC header
<sb0>
what?
<sb0>
LOL
<sb0>
the KC705 already has this ridiculous power supply design with several ARM CPUs; this is another level above it
<larsc>
there might be a secondary function
<larsc>
but if you don't run the right fw on the zynq the FMC headers is not powered up
<larsc>
s/is/are
fengling has quit [Ping timeout: 240 seconds]
<sb0>
duh
<larsc>
according to the documentation it is also supposed to act as an USB<->UART bridge
<larsc>
and no custom fw
<larsc>
'The system controller is delivered as a black-box design that communicates with onboard
<larsc>
programmable devices over an I2C interface'
<larsc>
'A Silicon Labs Si570 programmable low-jitter clock is used to provide a system clock for
<larsc>
FPGA designers. Through a UART (115200-8-N-1) text interface, the system clock (Si570)
<larsc>
can be set to any frequency between 10 MHz and 810 MHz.'
<larsc>
I guess having to I2C to program the clock chip was too complicated for most people
<larsc>
having to use I2C
flaviusb has quit [Quit: Leaving.]
<rjo>
interestingly, bitstream length is exactly the same for ku025, ku035, ku040. does that tell us something?
<rjo>
and also, since ku040 bitstreams exactly fill a 128 MBit flash (max for regular 24 bit adresses), i don't have to do too much mucking around with that idiotic dual-quad spi flash setup.
<rjo>
ku085 bitstreams are ~40% bigger than ku095.
<sb0>
yeah, most likely they have the same silicon in 25-40
<sb0>
as they do for artix
<sb0>
we can try to hack a ku25 into a ku40
<rjo>
ha. and the jtag instruction register length is exactly 6*number_of_dies. that smells like they want that for die-based boundary scan before stacking.
sb0 has quit [Quit: Leaving]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<whitequark>
wtf
<whitequark>
gdb-or1k pattern-matches function prologues generated by gcc
<whitequark>
why. why would you do this. you have perfectly working debug information right here, and the routines to use it
sb0 has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<sb0>
bb-m-labs, force build artiq-kc705-nist_qc1
<bb-m-labs>
build forced [ETA 11m39s]
<bb-m-labs>
I'll give a shout when the build finishes