sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<whitequark>
oh, it doesn't flush the cache to update the mailbox value. it flushes the dcache to create a synchronization point between CPUs, which otherwise lack cache coherency
<whitequark>
and dcache is write-through i guess, so you don't need that after send
_whitelogger____ has joined #m-labs
ylamarre has quit [Quit: ylamarre]
balrog has quit [Ping timeout: 252 seconds]
balrog has joined #m-labs
<sb0>
rjo, what is missing?
<sb0>
whitequark, the dcache is write-through, so there is no need to flush things if what you want is the writes to end up past it
<sb0>
and yes, the mailbox register is non-cacheable, the flush is there for the shared memory
fengling has quit [Quit: WeeChat 1.2]
fengling has joined #m-labs
<sb0>
travis is a PITA. no, it does *NOT* run easily locally.
<sb0>
$ source $HOME/miniconda/bin/activate py34
<sb0>
Error: could not find environment: py34
<sb0>
blah blah blah
<sb0>
why does anaconda-client depend on freetype, libpng and libjpeg?
<GitHub53>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vOTET
<GitHub53>
migen/master df2306a Sebastien Bourdeauducq: try to use the new anaconda-client
<sb0>
"This job ran on our legacy infrastructure. Please read our docs on how to upgrade"
<sb0>
god, this stuff is so high maintainance
<GitHub7>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vOTEo
<GitHub7>
artiq/master 4df2001 Sebastien Bourdeauducq: travis: try to use the new anaconda-client
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#356 (master - 4df2001 : Sebastien Bourdeauducq): The build has errored.
<whitequark>
sb0: will update tarballs in a moment
<sb0>
note to self: never use lwip in a new project again
<sb0>
RTOSes are bloated and often dirty, but less buggy
<sb0>
or uclinux, which is only bloated and quite reasonable wrt code quality
<sb0>
"Call tcp_sndbuf() to find the maximum amount of data that can be sent."
<sb0>
"The tcp_write() function will fail and return ERR_MEM if the length of the data exceeds the current send buffer size or if the length of the queue of outgoing segment is larger than the upper limit defined in lwipopts.h "
<sb0>
I'm sending the exact value returned by tcp_sndbuf() into that pile of trash, and it still returns ERR_MEM
<sb0>
"If the function returns ERR_MEM, the application should wait until some of the currently enqueued data has been successfully received by the other host and try again."
<sb0>
what a joke. it *always* returns ERR_MEM
<sb0>
"TCP sender buffer space (pbufs). This must be at least = 2 *TCP_SND_BUF/TCP_MSS for things to work."
<sb0>
well, NO.
<sb0>
the limit is higher
fengling has quit [Quit: WeeChat 1.2]
<GitHub67>
[artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vOkrJ
<sb0>
it's incredible how annoying this travis thing is
<GitHub138>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vOkb0
<GitHub138>
artiq/master 9b0ed34 Sebastien Bourdeauducq: runtime/Makefile: WA for more pesky travis/miniconda misbehavior
<whitequark>
meh. gen_service_table is gross
<sb0>
what else can you do?
<whitequark>
link ksupport and kloader together?
<whitequark>
then you could just &__whatever.
<sb0>
then you need to report errors across the CPUs
<whitequark>
huh?
<whitequark>
in what case would it differ from the current situation?
<whitequark>
I mean, you already pack an exception in a message and send it via the mailbox
<sb0>
if linking (which now happens on the kernel CPU, not comms) fails, what do you do?
<sb0>
also, this makes ksupport larger
<whitequark>
wait, why would linking happen on kernel CPU?
<whitequark>
(plot twist: I already implemented the behavior I am talking about, and it works, and it handles linking errors correctly)
<sb0>
how are you loading ksupport?
<whitequark>
I don't
<whitequark>
essentially, kloader_load does two things
<whitequark>
it loads and relocates the shared library onto KERNELCPU_PAYLOAD_ADDRESS
<whitequark>
and it copies a crt0 that would call kernel's main and exception handlers onto KERNELCPU_EXEC_ADDRESS
<sb0>
what about bridge.c?
<whitequark>
no functional change; kernel's main would receive NULL from the mailbox and call bridge_main()
<whitequark>
instead of some shared library entry point
<sb0>
well, meh
<sb0>
you are just saying ksupport becomes kernel's main
<sb0>
still: how do you load it?
<whitequark>
ksupport already was kernel's main? I didn't do anything to that part
<whitequark>
I don't load ksupport. its code is down there, with the runtime
<whitequark>
the crt0 at KERNELCPU_EXEC_ADDRESS calls directly into it
<whitequark>
just like a kernel would call into compiler-rt before.
<sb0>
so you are linking ksupport.c into the main binary, like a normal object file?
<whitequark>
yup
<whitequark>
there's only runtime.elf
<sb0>
mh
<sb0>
i like the idea of keeping the kernel CPU in its own address range
<whitequark>
hrm
<whitequark>
the linker really should reside in the kernel CPU then, imo
<whitequark>
I can do that if you want. not a lot of work
<sb0>
what's so wrong about gen_service_table?
<whitequark>
you're using python to do the job of the linker, poorly
<sb0>
it gets the job done, sufficiently
<whitequark>
there's no reason to add that complexity. all the tools are already there
<whitequark>
sigh
<sb0>
well, whatever. any of those three options is acceptable.
<whitequark>
k
<sb0>
if we are linking all into a single binary, maybe mark the kernel CPU sources clearly (e.g. put them in a different folder) as the errors will be more obscure than linking failure if a kcpu-only function is incorrectly used on the comms-cpu
<rjo>
sb0: that offer is void in the case where you guys break stuff, meddle with it, then give up and complain about how difficult things are. it assumes responsible behavior. and I did point you to what i suspect is the breakage.
<rjo>
sb0: how ironic to see you bitch about how hard it is to install artiq.
<rjo>
sb0: also please do proper commit messages.
<cr1901_modern>
I wonder how much trouble I'll get into during synthesis if I use a GPIO as an input for a clock that only drives one module...
<ylamarre>
None at synthesis, it will creep back at pnr though ;)
<ylamarre>
or map, not 100% ure.
ylamarre1 has joined #m-labs
ylamarre has quit [Ping timeout: 240 seconds]
<cr1901_modern>
Well, I'll have to take a risk then lol
<cr1901_modern>
It appears in Migen, unless I'm mistaken, one can only generate always@ blocks around pins that will be given clock attributes in the UCF (TNM_NET in Xilinx).
<cr1901_modern>
So idk if PAR or map will complain that I'm trying to assign clock attributes to a GPIO pin (I don't have a choice).
ylamarre1 has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
<whitequark>
sb0: no, it won't, since master uses -integrated-as already
<whitequark>
let me finish this runtime thing and I'll write the conda scripts...
ylamarre has quit [Remote host closed the connection]