06:33 <cr1901_modern> whitequark: What's liballoc? Is that a malloc you decided to write?

06:34 <whitequark> yes

06:35 <cr1901_modern> Guess openmem didn't fit your needs?

06:37 <cr1901_modern> Hrm, where is root initialized?...

06:38 <whitequark> static variables are initialized to NULL

06:38 <whitequark> openmem is too complex

06:39 <cr1901_modern> While I didn't actually know that, I was referring to how one gives root a valid initial memory address. Looks like it's in alloc_give()

06:40 <cr1901_modern> So e.g. alloc_give() would be part of the startup code I'm guessing

06:40 <whitequark> grep it...

06:44 <cr1901_modern> Should prob build a SoC. In any case, that's cool... probably one of the simplest possible mallocs!

17:37 <rjo> cr1901_modern: the proxy bitstreams are just one register and one gate. they don't care what files you write, not do they even understand spi. it just happens that spi and jtag are pretty much the same and thus "jtagspi" for openocd is merely a flash writing and reading tool. also there it does not care what you write. it is just that the fpgas expect the raw bitstream in the flash, not the .bit (which just has a bit of trivial metadata attached to it). special

17:43 <cr1901_modern> rjo: Ack. Incidentally, your bitstreams do not work with xc3sprog, but I don't have time to figure out why

17:44 <whitequark> iirc they're different for xc3sprog and openocd

17:46 <rjo> yes. that is intentional. little in the xc3sprog proxy bitstreams makes sense but is expected by xc3sprog.

17:47 <cr1901_modern> Is it documented how to build a xc3sprog bitstream? I mean, I'd love to use OpenOCD for all my JTAG needs but it does not appear to support programming Spartan 3 boards (yet)

17:55 <cr1901_modern> _florent_: It's very possible I'm misremembering, but didn't litescope use to exist as part of MiSoC? https://github.com/m-labs/misoc/search?utf8=✓&q=litescope

18:20 <rjo2> spartan3 should not be more than a handful of tcl lines.

18:26 <cr1901_modern> rjo2: While I could still be wrong, there was something else that made me put off porting. The Spartan6 OpenOCD code relies on a specific driver that seems family-specific to actually load the code.

18:27 <cr1901_modern> rjo2: Here we go http://openocd.zylin.com/gitweb?p=openocd.git;a=blob;f=tcl/cpld/xilinx-xc6s.cfg;h=9ce7ad4918d43924bc0aa6316faf8bd53ab221cc;hb=08a32a52f7724374ef5b6966f9a6bc2e9610133d#l26

18:27 <cr1901_modern> virtex2 is the only driver supported

18:29 <rjo2> spartan6 is also not virtex2 nor is kintex7. I would just try it.

18:32 <cr1901_modern> According to the history, you wrote that line :P. But if you don't remember why, I guess I'll try and see what happens. Note that it's a PLD command

18:38 <cr1901_modern> rjo2: This is a stupid question, but... how do you get a TCL REPL in OpenOCD? XD

18:39 <cr1901_modern> Okay nevermind... it appears telnet is the proper way

18:42 <rjo2> yes. FPGA is a pld. the virtex2 thing was generic enough for s3 and s6

18:42 <rjo2> aeh. s6 And k7

18:42 <rjo2> I would guess it also works for s3

18:43 <rjo2> just starting openocd gives you a reply, iirc

18:44 <cr1901_modern> I had to open a telnet session to actually get a REPL... that's fine (on Windows). Well, I'll try s3 and see what happens, and hopefully submit a patch soon

18:55 <whitequark> sb0__: ah you're going to love my solution for that issue

19:11 <rjo2> cr1901_modern: are you doing openocd on windows for artiq?

19:11 <rjo2> is openocd on windows very painful?

19:14 <cr1901_modern> rjo2: Well, I'm doing openocd on Windows to test HDMI2USB firmware (get acquainted w/ building it), and also test-driving it for my other micros and FPGA boards.

19:14 <cr1901_modern> It's not anymore painful than any autoconf-based piece of software that assumes POSIX is the One True Standard

19:15 <cr1901_modern> To access FTDI-based chips, I have to use the Zadig driver

19:15 <cr1901_modern> well, any chip besides FT2232 (sic), where one of the channels can use the standard driver as a UART

19:16 <cr1901_modern> Whatever MSYS2 uses for terminal input and output doesn't really work all that well, so I can't actually use OpenOCD from a terminal

19:16 <cr1901_modern> I have to open a telnet session using PuTTY, which I don't really mind

19:17 <cr1901_modern> This is the board I'm using for programming when the JTAG headers are exposed: http://int3.cc/products/the-shikra

19:35 <whitequark> mmmm, miscompilation bugs. I like those

19:42 <larsc> if you can't trust the compiler whom can your really trust?

19:42 <larsc> you

19:45 <bb-m-labs> build #52 of artiq-pipistrello-nist_qc1 is complete: Failure [failed conda_build] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq-pipistrello-nist_qc1/builds/52 blamelist: whitequark <whitequark@whitequark.org>

20:12 <whitequark> sb0__: wow, that vsnprintf code is seriously crappy

20:40 <rjo> cr1901_modern: i actually remember having openocd talk to a s3.

20:42 <sb0> rjo, i think you probably wrote this. could you answer this email? https://ssl.serverraum.org/lists-archive/artiq/2016-January/000686.html

20:44 <rjo> sb0: sure. already had it tagged.

20:44 <rjo> oh. are you on NISTGuest or the like?

20:44 <sb0> NIST-Visitor, yes

20:45 <rjo> i suspect that might be an advantage of not having the plastic badge...

20:45 <sb0> for some reason, it seems it has become easier to get wifi accounts and harder to get no-escort badges...

20:46 <rjo> yep. if you need me for pyqt5 discussions (and the talk is over), let me know.

20:46 <rjo> i think the two are also mutually exclusive

20:48 <sb0> talk is still going, then there is the phone conf at 2

20:51 <rjo> there or in the small conf room here?

20:52 <GitHub36> [misoc] whitequark pushed 2 new commits to master: https://github.com/m-labs/misoc/compare/8e401f1c01a7...4db0c6ad853e

20:52 <GitHub36> misoc/master 39146c9 whitequark: libbase: fix completely broken vsnprintf.

20:52 <GitHub36> misoc/master 4db0c6a whitequark: Import fdlibm.

20:53 <bb-m-labs> build #101 of artiq is complete: Failure [failed] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq/builds/101 blamelist: whitequark <whitequark@whitequark.org>

20:56 <GitHub128> [buildbot-config] whitequark pushed 1 new commit to master: https://github.com/m-labs/buildbot-config/commit/3b8b7b99d567653fdb249e38f7f7c970363bbfcd

20:56 <GitHub128> buildbot-config/master 3b8b7b9 whitequark: Raise conda build timeout to four hours.

20:57 <whitequark> rjo: I will need to think about it, there are many subtle potential issues with your proposal

20:57 <whitequark> not sure if it's viable just yet.

20:58 <whitequark> in principle I made the new compiler from the start so that it would support workloads like this

20:58 <whitequark> ... but it's entirely possible that some soundness bug will prevent clever things like this from working.

21:03 <GitHub179> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/1b9713115c7e8a770eb027b3c6e2ffec6a12918d

21:03 <GitHub179> artiq/master 1b97131 whitequark: runtime: link libm and libbase-nofloat where appropriate.

21:05 <bb-m-labs> build #102 of artiq is complete: Success [build successful] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq/builds/102

21:05 <rjo> whitequark: multiple kernels (at least one being "staged" by the comms-cpu and one being executed by the kernel-cpu and then "fast" flip between the two) will need to land anyway.

21:06 <whitequark> rjo: no, flipping is simple.

21:06 <whitequark> it's calling which is harder.

21:07 <rjo> whitequark: ack.

21:09 <whitequark> rjo: I would really like to hear what will this be used for

21:11 <whitequark> at least this will guide the feature, at most it should be replaced with something else entirely

21:13 <whitequark> generally, what you want has very many correctness hazards. host objects not being updated, LIFO ordering on kernels not being maintained, very complicated liveness analysis for allocated objects

21:50 <bb-m-labs> build #53 of artiq-pipistrello-nist_qc1 is complete: Success [build successful] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq-pipistrello-nist_qc1/builds/53

22:25 <GitHub89> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/a9cf89215bb3d7fc5b947eb7be9e9e937bdfecf6

22:25 <GitHub89> artiq/master a9cf892 Sebastien Bourdeauducq: coredevice/dds: use explicit 64-bit ints for ftw computations

22:27 <bb-m-labs> build #57 of artiq-kc705-nist_qc2 is complete: Failure [failed conda_build] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq-kc705-nist_qc2/builds/57 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

22:29 <sb0> whitequark, Error: HTTPError: 404 Client Error: Not Found for url: http://conda.anaconda.org/m-labs/channel/dev/noarch/artiq-0.0-py_2407+gita9cf892.tar.bz2: http://conda.anaconda.org/m-labs/channel/dev/noarch/artiq-0.0-py_2407+gita9cf892.tar.bz2

22:30 <whitequark> http://101.78.236.68/buildbot/builders/artiq/builds/103/steps/anaconda_upload/logs/stdio

22:30 <whitequark> complete according to this

22:30 <whitequark> so, it's an anaconda bu.

22:30 <whitequark> bug.

22:56 <bb-m-labs> build #58 of artiq-kc705-nist_qc2 is complete: Success [build successful] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq-kc705-nist_qc2/builds/58