<cr1901_modern>
rjo: For context, I decided to move an FPGA board I need to program (minispartan6+) to a Linux SBC that I have (old Beagleboard). It's running Debian Jessie. It comes with OpenOCD 0.8. jtagspi: No such flash driver
<cr1901_modern>
Oh look, openocd 0.9 was backported :D. jtagspi: No such flash driver
<cr1901_modern>
rjo: Looks like it was commited already? Just not in the current stable version?
<rjo>
cr1901_modern: which "it"?
<cr1901_modern>
rjo: The whole patch set. But I think I misinterpeted the following line >>
<rjo>
the patch is almost one year old and brings the proxy bitstreams up to new migen. jtagspi itself is in master (0.10?)
<cr1901_modern>
rjo: Okay, so just add a comment where all the "patch set X: Code-Review+1" comments are querying the status?
<cr1901_modern>
"jtagspi itself is in master (0.10?)" Well that's good, but doesn't really help me in this case, since I'll have to compile from source. I hope it's better behaved than on MSYS2...
<rjo>
yes. just a bump. might accelerate that process a bit.
<rjo>
as i said. we have conda packages that you can use.
<rjo>
but it is well behaved under debian.
<cr1901_modern>
rjo: Do you have conda packages for ARM? B/c that's what I was compiling for.
<rjo>
ah. no. but compiling should be smooth.
<cr1901_modern>
rjo: Done
sb0 has joined #m-labs
<whitequark>
sb0: how likely it is do you think that the comms CPU has broken atomics?
<sb0>
why the comms CPU specifically? it's the same as the kernel CPU
<whitequark>
in case it has different configuration options, but yes
<whitequark>
I'm observing very bizarre behavior
<rjo>
broken in gateware?
<sb0>
how are the atomics implemented (and why do coroutines need atomics anyway)?
<whitequark>
they don't
<whitequark>
I'm using the builtin logger, which uses atomics to manage a global instance
<whitequark>
on a high level, if I follow an atomic store with an atomic load immediately, then loads further down the line return the new value
<whitequark>
if I do not they return the old value
<sb0>
stekern, ^
<whitequark>
actually it seems even weirder than that, I need to follow and precede it with an atomic load?
<whitequark>
it's not very minimal...
<whitequark>
but yes, it looks as if, if I surround the store with two loads, then it gets recorded, otherwise it doesn't
<stekern>
how are those used? I don't even see anything checking for the flag from l.swa
jaeckel has quit [Quit: Goodbye Cruel World]
<whitequark>
do I need to check the flag if I didn't do a load-linked before?
<whitequark>
what is supposed to happen is that _ZN3log17MaxLogLevelFilter3set17h38da651c9b04d548E gets called once
<whitequark>
and it does that store, and puts the value there
<whitequark>
then, sometime in the future _ZN3log17MaxLogLevelFilter3get17h4f60bdb38398a177E gets called many times and extracts the value
<whitequark>
what I see is an apparent failure to do that store
jaeckel has joined #m-labs
mumptai has joined #m-labs
<stekern>
well, the l.lwa/l.swa is supposed to be used as a pair. You start the sequence with a l.lwa, then when you do a l.swa it only succeed if the previous l.lwa was to the same address and no-one else has touched that address since the l.lwa
<stekern>
...and upon success the flag will be set
<whitequark>
so how do I do a lone atomic store?
<whitequark>
I don't care what was there before
<stekern>
if you don't care what was there, what's wrong with just l.sw?
<whitequark>
so what you're saying is that l.swa is not equivalent to e.g. a lock mov
<whitequark>
and can only be used as a part of ll/sc loop. right?
<stekern>
the point of l.lwa/l.swa is to be able to do an atomic RMW
<stekern>
right
<whitequark>
ok, so it's like ldrex/strex rather than lock mov
<whitequark>
ok.
<whitequark>
thanks.
sandeepkr__ has quit [Read error: No route to host]
sandeepkr__ has joined #m-labs
<sb0>
_florent_, how is the jesd core coming along? have you done tests on the board already?
<_florent_>
sb0: I'm doing the first tests right now: ad9516 and 9514 should be configured correctly, I'm looking if ad9154 receives the data correctly
balrog has quit [Ping timeout: 252 seconds]
<larsc>
_florent_: I don't think any of the DACs care, but the spec says you should send a incrementing counter in the unused field of the ILAS
Gurty has quit [Ping timeout: 240 seconds]
<whitequark>
stekern: does or1k even have a cache coherency model?
<whitequark>
as in, I currently just translate atomics to corresponding loads/stores, but...
<whitequark>
but that's not really legal in a weak memory model
Gurty has joined #m-labs
<whitequark>
normally I would insert an appropriate barrier, but it doesn't appear that or1k defines one
<whitequark>
like, there's l.msync, which, as far as the doc goes, clears the store buffer and that's it
<whitequark>
it doesn't guarantee that any stores have been made visible to other cores