<sb0>
we can probably recycle it for sdram core device storage
<whitequark>
sb0: perhaps, but that doesn't solve the problem of flash storage...
<whitequark>
btw did you add that kenrel cpu "MPU" yet?
<sb0>
whitequark, have you looked at /artiq/runtime/flash_storage.h?
<whitequark>
oh yes, but isn't it severely limited in size?
<whitequark>
one sector
<sb0>
it is, and it is slow. but I don't know what need to be stored there anyway, we should clarify
<whitequark>
I got the impression that this was instead the feature which allowed to store large arrays in .rodata
<sb0>
in sdram yes, but I'm not sure why one would store them in flash
<whitequark>
generally speaking, storing stuff in flash is more error-prone but also more general if you absolutely hae to to recompile and your data is huge
<whitequark>
since even if it's in rodata... upload takes a while
<sb0>
transfer speed should be something like 1MB/s...
<sb0>
though the comms code will have issues with large kernels I think... or did you fix that?
<whitequark>
what problem was it again?
<whitequark>
I might have
<sb0>
the buffer size is limited
<sb0>
(per packet)
<whitequark>
ah yeah that is true
<sb0>
that's easy to increase, but you will quickly exceed the sdram size on pipistrello
<whitequark>
the proper solution is to allow loading the kernel in multiple packets, whcih is easier than that core device storage thing
<sb0>
felix_, speaking of, how is PPP going?
<sb0>
whitequark, yes, that works too
<whitequark>
but first we need to figure out what exactly is that for anyway
<sb0>
whitequark, core device storage is just a hash table of binaries exposed to kernels... how is that hard?
<sb0>
well, not necessarily hash, key/value
<whitequark>
I would need to reuse serialization code and add some compiler support
<whitequark>
it's not *hard*, it's just harder than fixing packet length isue
<sb0>
whitequark, your linker has no problem loading binary in-place, right?
<sb0>
i.e. put the ELF file somewhere in RAM, and execute directly from there, without any copy
<whitequark>
that is actually the only mode it supports
sb0_ has joined #m-labs
sb0 has quit [Read error: Connection reset by peer]
Mon_ has joined #m-labs
Mon_ is now known as Guest41139
Guest41139 has quit [Client Quit]
sb0 has joined #m-labs
sb0_ has quit [Read error: Connection reset by peer]
rjo_ has quit [Ping timeout: 240 seconds]
<GitHub20>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/v0SXh
<GitHub20>
artiq/master 6ae41e6 Sebastien Bourdeauducq: runtime/net_server: refactor to support multiple services
Mon_ has joined #m-labs
Mon_ is now known as Guest20809
Guest20809 has quit [Quit: This computer has gone to sleep]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
sb0_ has joined #m-labs
sb0 has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
sb0 has joined #m-labs
sb0_ has quit [Read error: Connection reset by peer]
<sb0>
of course, gnu/autocrap fails when attempting to build openocd
kristianpaul has quit [Remote host closed the connection]
ylamarre has quit [Ping timeout: 265 seconds]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
kristianpaul has quit [Changing host]
ylamarre has joined #m-labs
<rjo>
sb0: what's the command and the error you are getting? remote testing (booting with volatile or flashed bitstreams etc) has always been working fine for me.
ylamarre has quit [Ping timeout: 272 seconds]
<felix_>
sb0: haven't found the bug in the ppp stack yet. i still have to test a few hardware dependent things, but if that doesn't reveal the underlying bug, i'll probably port the software to some arm cortex-m4 based controller and debug it there
bentley` has quit [Remote host closed the connection]