01:03
<
GitHub >
artiq/master c2cf60e whitequark: firmware: use the cslice crate to get rid of unsafe code in ksupport.
01:03
<
GitHub >
artiq/master 9a9a3aa whitequark: firmware: remove unnecessary inline assembly in libboard.
01:08
<
GitHub >
artiq/master 0df8a24 whitequark: Fix c2cf60e.
05:27
<
GitHub >
artiq/master 3b54736 whitequark: firmware: port flash storage management to Rust.
05:47
<
sb0 >
whitequark, #569 "there will still be -lcompiler-rt+-lalloc needed by Rust and -lbase needed by lwip" << can -lbase go?
05:47
<
whitequark >
sb0: needs the uart junk ported
05:48
<
whitequark >
and, hm, something else, let me check
05:50
<
whitequark >
ah yes. liballoc also depends on -lbase. and there are a few strlen invocations that should die once the compiler finally uses pascal strings.
08:07
bentley` has quit [Ping timeout: 256 seconds]
08:41
kilae has joined #m-labs
09:16
<
sb0 >
the si5324 isn't properly locking
09:16
<
sb0 >
that can explain the DRTIO fuckups
09:45
<
rjo >
sb0: got about 10 more codenames for sinara?
09:51
<
sb0 >
novogorny, berdenish, bolshaya, sary, urukul, zotino, koster, mirny, selki, kirdy
09:52
<
whitequark >
sb0: ...
10:19
<
sb0 >
whitequark, can you go over the si5324 programming again and see if you can figure out why LOL_INT stays at 1?
10:19
<
whitequark >
sb0: ok. let me finish what I'm doing now and I'll go that
10:33
<
sb0 >
why are you clearing a reserved bit (D2) in register 0?
10:34
<
whitequark >
typo, probably
10:56
<
GitHub >
artiq/master 259319e whitequark: firmware: use compiler_builtins crate instead of our compiler-rt....
10:56
<
GitHub >
artiq/master 44a9a79 whitequark: firmware: port allocator to Rust.
10:56
<
whitequark >
we're now down to only base-nofloat in runtime
10:56
<
whitequark >
so that's just the UART.
10:59
<
whitequark >
oh, and also strlen
11:10
<
GitHub151 >
rust/master 96c52d4 Esteban Küber: Add unittest
11:10
<
GitHub151 >
rust/master 521b2ea Ariel Ben-Yehuda: clear discriminant drop flag at the bottom of a ladder...
11:10
<
GitHub151 >
rust/master 40053a4 Yamakaky: Impl From<Ipv4Addr, Ipv6Addr> for IpAddr....
11:35
<
whitequark >
hmm, why did that start failing
11:43
<
whitequark >
... hm
11:43
<
whitequark >
the cslice commit?!
11:56
<
whitequark >
this makes utterly zero sense
11:57
<
sb0 >
cache problems?
11:57
<
sb0 >
see also #485
11:59
<
whitequark >
sb0: hm
11:59
<
whitequark >
can I get performance counters?
11:59
<
whitequark >
instruction counter, l1/l2 miss counter
12:00
<
whitequark >
and I guess I can build a sampling profiler in other ways already
12:05
<
sb0 >
I'm not familiar with the mor1kx code
12:05
<
whitequark >
sb0: oh I know what happens.
12:05
<
whitequark >
indeed cache effects.
12:06
<
whitequark >
specifically, the test relies on exceptions, and an exception will invoke the unwinder, which is... large
12:23
<
whitequark >
sb0: hm I can make rtio_output about 2x faster by fixing llvm
12:23
<
whitequark >
right now it generates shit like this
12:23
<
whitequark >
40803be0: a9 88 00 4c l.ori r12,r8,0x4c
12:23
<
whitequark >
40803be4: d4 0c 30 00 l.sw 0(r12),r6
12:23
<
whitequark >
should be just l.sw 0x4c(r12),r6 no?
12:24
<
GitHub >
artiq/master 9c93c76 whitequark: firmware: do not use PIC in Rust code....
12:25
<
whitequark >
sb0: actually... why did we switch to PIC in the first place?
12:25
<
whitequark >
there was some reason that I don't remember. but everything works without PIC.
12:30
<
sb0 >
you wanted the kernels to be PIC
12:30
<
rjo >
whitequark: i had seen similar code and wondered. must have forgotten to point it out.
12:31
<
whitequark >
sb0: yeah but that seems unrelated to runtime/ksupport being PIC
12:31
<
whitequark >
every function loads the PIC base itself
12:31
<
whitequark >
oh, maybe I thought that isn't the case.
12:41
<
whitequark >
sb0: what's the problematic set of settings for si5324?
12:41
<
sb0 >
why is the si5324 acting up...
12:41
<
sb0 >
I can't even get it to lock to its crystal
12:41
<
sb0 >
whitequark, absolutely nothing works. it never locks.
12:42
<
whitequark >
are you absolutely sure the conversions are correct?
12:42
<
sb0 >
at least with the 62.5MHz settings
12:42
<
whitequark >
well, let me check them
12:42
<
whitequark >
what about the old settings we used?
12:42
<
sb0 >
those should be the 62.5MHz settings
12:44
<
whitequark >
sb0: uhm
12:48
<
whitequark >
sb0: ok, how do I build/run satman?
12:50
<
whitequark >
sb0: btw you haven't added loop bandwidth to parameters
12:50
<
whitequark >
if you're using the new parameters, can you set BWSEL_REG to what it says and try again?
12:52
<
whitequark >
sb0: wohoo, turning off PIC made pulse rate tests pass
12:52
<
sb0 >
I've already tried BWSEL_REG=1, no effect
12:53
<
whitequark >
although for some utterly inexplicable reason they're still slower on CI than locally
12:53
<
sb0 >
whitequark, good!
12:54
<
sb0 >
whitequark, run kc705_drtio_satellite.py
12:54
<
sb0 >
add --integrated-rom-size 32768 if that helps
12:55
<
GitHub >
artiq/master 90ac915 Sebastien Bourdeauducq: firmware: do not clear si5324 reserved bit
12:55
<
GitHub >
artiq/master 6bea253 Sebastien Bourdeauducq: firmware: fix misleading si5324 comment
12:56
<
whitequark >
sb0: oh
12:56
<
whitequark >
did that bit just get inverted inadvertently?
12:56
<
sb0 >
I have a bitstream in ~/artiq_drtio if you want
12:56
<
sb0 >
that's the one I mentioned above. fixing it did not improve things.
12:57
<
whitequark >
oh, hm
12:57
<
whitequark >
sb0: have you tried rebooting the board?
12:57
<
whitequark >
I vaguely recall some bug related to si5324 that went away after a reboot
12:59
<
sb0 >
no, let me try on the other kc705
13:04
<
sb0 >
btw, the fpga may generate some garbage on clkin1, may be better to try locking the 5324 to its crystal first
13:12
<
whitequark >
sb0: your values for 62.5mhz are nuts
13:12
<
whitequark >
where did you get them from?
13:17
<
sb0 >
the fpga may not generate a valid clkin, and setting n32 to 0 isn't the right way to disable clkin2 afaict
13:17
<
sb0 >
also, why are my value nuts? the large integers are expected
13:20
<
whitequark >
the divisor has large integers because of the crystal
13:27
<
whitequark >
maybe write(21, 0b11111100)?; ?
13:27
<
whitequark >
though I don't think that should affect anything
13:27
<
whitequark >
also can you read register 128 and see if it does in fact use the correct clock as PLL input?
13:32
<
sb0 >
yes, it switches to the correct clock
13:32
<
sb0 >
e.g. changing clock priorities affect register 128 normally
13:33
<
sb0 >
write(21 didn't change anything
13:35
<
whitequark >
I don't see anything else that may be wrong
13:35
<
whitequark >
ask silabs?
13:39
<
sb0 >
hm, the C code worked before
13:41
<
whitequark >
but this uses the old divider values.
13:41
<
whitequark >
the ones I gave you above in a hastebin link
13:43
<
sb0 >
okay, those fail as well
13:43
<
whitequark >
hm, that seems troublesome
13:43
<
sb0 >
yes. typical shit when dealing with any sort of proprietary chip
13:46
<
sb0 >
maybe the mapping code does the wrong thing
13:46
<
sb0 >
ffs I hate this
13:47
<
sb0 >
I wonder how much of this garbage the hmc* will give us on sinara
13:47
<
whitequark >
sb0: afaict it doesn't do the wrong thing
13:47
<
whitequark >
I checked it twice
13:49
<
larsc >
the hmc wont give any garbage ;)
14:05
<
sb0 >
okay, disabling "fast lock" makes it work
14:05
<
sb0 >
now, is that awful drtio bug still there...
14:07
<
sb0 >
panic at src/libcore/slice.rs:519: destination and source slices have different lengths
14:09
<
sb0 >
whitequark, that's when I try to artiq_run the kernel that produces the bug
14:11
<
rjo >
sb0, whitequark: we are at 5.6 GB of 3 GB on anaconda. lots of llvm, rustc, whitequark, could you clean up there?
14:21
<
sb0 >
and the drtio bug is still there, of course.
14:22
<
sb0 >
in a different form
14:22
<
sb0 >
hm, so it did something
14:32
ohama has quit [Ping timeout: 258 seconds]
14:42
ohama has joined #m-labs
14:57
kuldeep has quit [Ping timeout: 252 seconds]
14:58
<
sb0 >
seems this was due to the network packet buffer changes, but now network is completely broken after recompiling master (with the drtio design)
14:59
<
sb0 >
also I cannot get this shitty si5324 to lock again
15:18
<
GitHub >
artiq/master aafefee Sebastien Bourdeauducq: targets: make number of ethmac slots consistent
15:32
bentley` has joined #m-labs
17:38
<
whitequark >
sb0: so... how do I repro?
18:53
<
GitHub >
artiq/master 5a30536 Robert Jordens: doc: write section on developing with a conda env
18:53
<
GitHub >
artiq/master edab068 Robert Jordens: conda: pull in openocd in artiq and artiq-dev
18:58
<
GitHub >
artiq/master 02917aa Robert Jordens: doc: newline after label
19:04
<
GitHub >
artiq/master 9c64680 Robert Jordens: doc: fix verbatim sections
19:22
<
rjo >
bb-m-labs: build conda-all --package=openocd
19:29
<
GitHub85 >
conda-recipes/master f975744 Robert Jordens: openocd: build 0.10.0 release
19:55
<
GitHub161 >
conda-recipes/master 4e105b2 Robert Jordens: openocd: rm non-ascii files
19:56
<
whitequark >
rjo: uhm, how do you expect that to work?
19:56
<
whitequark >
в is two utf-8 bytes
19:56
<
whitequark >
it won't be matched by a single shell ?, I don't think
20:06
cr1901_modern has quit [Ping timeout: 255 seconds]
20:12
cr1901_modern has joined #m-labs
20:13
<
cr1901_modern >
Huh, FTDI serial driver caused a BSOD... that's a first for me.
20:40
<
rjo >
whitequark: whoever wrote the windows build scripts did that.
20:40
<
rjo >
whitequark: and at least in my shell it works fine.
20:41
<
rjo >
whitequark: i.e. ? is in codepoints.
20:49
MiW has quit [Ping timeout: 260 seconds]
21:07
kilae has quit [Quit: ChatZilla 0.9.93 [Firefox 51.0.1/20170125094131]]
21:14
MiW has joined #m-labs
21:20
mumptai has joined #m-labs
21:21
<
GitHub >
conda-recipes/master 95332e5 Robert Jordens: openocd: rm more non-ascii files
22:48
<
GitHub >
conda-recipes/master 7a600c4 Robert Jordens: openocd: bump
23:09
mumptai has quit [Quit: Verlassend]
23:16
<
sb0 >
whitequark, compile kc705_drtio_satellite+satman, load into a kc705
23:17
<
sb0 >
I recommend to try locking the 5324 to its crystal first, clkin1 generated by the fpga has a lot more moving parts
23:29
kuldeep has joined #m-labs