<felix_>
_florent_: is it intentional that only odt0 (and not odt1) is driven on kc705? for single rank modules this makes no difference, but i'm not sure if this might cause problems with dual rank modules. even if there's no dual rank support, i'd drive the odt1 pin to the level where the second rank can't interfere with the first rank. same for the chip select inputs of the sodimm
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
<bb-m-labs>
build #1796 of artiq is complete: Exception [exception interrupted conda_remove] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1796 blamelist: whitequark <whitequark@whitequark.org>
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<felix_>
hmm, how should i deal with the muxes between the gtp clocks on the fmc connector and the gtp clock inputs of the fpga on the ac701? it seems that there's currently no abstraction for that, since there aren't clock multiplexers on the kc705
<whitequark>
sb0: requesting permission to add a feature to the UART that resets the entire gateware
<whitequark>
why? this solves a *lot* of problems in one go. 1. no need for racy coordination between artiq_flash reset and flterm. 2. no need for hardcoded tftp addresses. 3. works without functional ethernet. 4. does not have the issue where the UART and the JTAG dongle don't match each other.
<whitequark>
5. if the bitstream is not flashed but merely loaded, then this permits resetting soft-CPU without losing the bitstream as a side effect of JTAG reset (I think)
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<GitHub-m-labs>
[buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vbe8r
<GitHub-m-labs>
buildbot-config/master 89cff68 whitequark: Remove an extraneous suffix.
bb-m-labs has joined #m-labs
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub152>
[smoltcp] whitequark commented on pull request #75 7e94c56: No, this just means that servers may insert pad options if they want, and clients should ignore them. It's for convenience of server implementers. https://github.com/m-labs/smoltcp/pull/75#discussion_r153166796
<whitequark>
sb0: no
<whitequark>
TFTP is too annoying to coordinate
<whitequark>
I have to carefully time *three* processes: FPGA reset, input through console, and TFTP upload
<whitequark>
kthx no
<whitequark>
as for loading and not flashing the bitstream, well right now that's too annoying because I use `artiq_flash start` as a SoC reset
X-Scale has joined #m-labs
<whitequark>
the reason being that whatever's flashed there is not necessarily available on the same host where artiq_flash is running
<sb0>
so you prefer storing the bitstream in the board's flash than on the lab computer's hard disk? how does that make thing easier?
<whitequark>
because if I make a mistake somewhere and instead of loading the bitstream from hard disk it gets loaded from the flash, I get bizarre bugs
<whitequark>
if there's only one source of truth (flash that is) there can be no chance of that
<whitequark>
you have no idea how much time I wasted on this stuff
<whitequark>
anyway, if I can load a bitstream *and never touch JTAG again*, then your proposed workload is OK
<whitequark>
which is why I want this functionality in the UART
<sb0>
doesn't the bios boot from tftp if the flash is empty?
<sb0>
then the timing is simply: prepare tftp server, then after the server is ready, load the bitstream
<whitequark>
that's not "simply" at all
<whitequark>
that's just more variables: whether the buildbot flashed it. whether you or rjo flashed it.
<sb0>
you can write a script that locks the board for you and then erases the flash
<whitequark>
95% of the time I want just "whatever was the last bitstream the buildbot loaded into SoC"
<whitequark>
so this will require messing with conda channels, keeping an updated bitstream somewhere, ...
<sb0>
you just said that whatever was in the flash is not reliable, e.g. if someone else flashed it
<sb0>
or we can agree that only the buildbot should touch the flash
<whitequark>
that's the idea, yes
<whitequark>
the buildbot touches flash and JTAG, nothing else does
<sb0>
how do we debug gateware then? this needs modifying the bitstream
<whitequark>
hm, correction: the buildbot touches flash, anyone who needs new bitstream touches JTAG, anyone who only needs new firmware touches UART
<whitequark>
that would be ideal IMO
<sb0>
why UART and not a FPGA reset from OpenOCD, which is 1 command and can be done using existing features?
<whitequark>
because that's racy
<sb0>
not really, you just open the serial port before issuing the openocd command
<whitequark>
that doesn't actually work because spawning flterm takes a ton of time
<whitequark>
so, unless I specifically look at something in flterm's output indicating that it is listening, I can't issue any openocd command
<sb0>
flterm is python, you can import it and run the parts that you want from artiq_devtool perhaps?
<sb0>
also make sure that the artiq bitstreams don't erase it
<sb0>
using the same tool
<sb0>
maybe the value can be interpreted as a TFTP IP address, and if it is a valid IP, the BIOS does nothing else but TFTP
<sb0>
this USR_ACCESSE2 just gives you the register value as a regular FPGA signal, it seems
<whitequark>
actually, artiq bitstreams *should* erase it
<whitequark>
since they ought to boot from flash by default
<sb0>
also it would be nice if 1. your TFTP server deletes the file after it has been downloaded once 2. the buildbot erases the register value
<sb0>
or the buildbot uses the same TFTP mechanism.
<sb0>
well no, you want to 1. write register 2. load stock artiq bitstream
<whitequark>
sure, the buildbot using this infra is blocked on the very same issues
<whitequark>
how about 1. load stock artiq bitstream 2. write register 3. release reset?
<whitequark>
or even further
<whitequark>
1. write register 2. reset ?
<whitequark>
(in case the BIOS in the flash is functional)
<whitequark>
(and the bitstream is useful)
<whitequark>
vivado docs say the value can be reconfigured on the fly
<whitequark>
ok, I believe that will work
<whitequark>
thanks!
<whitequark>
sb0: btw the ethernet switch issue
<whitequark>
it's errors in the preamble
<whitequark>
I didn't thoroughly go through the gateware for that yet, it's written in some convoluted way
<whitequark>
sb0: speaking of that, at this point, it would be extremely easy to add SLIP support to smoltcp
<whitequark>
so that sayma could be used even without working Ethernet
<whitequark>
any interest in that?
<GitHub77>
[smoltcp] whitequark commented on issue #55: I have reconsidered it and, indeed, it makes perfect sense. Also, we can just have a `ManagedSlice<'a, Managed<'b, for<'c> Device<'c>>>` to avoid using `Box`. https://github.com/m-labs/smoltcp/issues/55#issuecomment-347164557
<sb0>
is there any reason for the gateware to check the preamble at all?
<sb0>
if the frame CRC is valid, we can assume there was a legit attempt to send us the frame, no?
<sb0>
whitequark, 1. load stock artiq bitstream 2. write register << that has a race
<sb0>
SLIP, yes, if it's indeed extremely easy
<whitequark>
sb0: load but keep in reset
<sb0>
and how do you unreset?
<whitequark>
well I assume openocd can do that somehow
<sb0>
hmm maybe. this needs digging into openocd.
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
but re. SLIP, the priority should be to get the ethernet core to actually work...
<sb0>
whitequark, so if we kill the preamble checker in the ethernet core, is the switch issue gone?
<sb0>
_florent_, any ideas?
<whitequark>
sb0: haven't checked yet
<whitequark>
sb0: why does netboot() try to pull files from tftp server as opposed to the other direction?
<whitequark>
I imagine `put bios.bin main_ram` would be better
<sb0>
I guess you can simply change it to the other direction ...
<whitequark>
ok
<sb0>
whitequark, oh, I remember, that's because it would also download a linux initrd
rohitksingh has joined #m-labs
<sb0>
_florent_, in hmc830 you changed this:
<sb0>
- (0x3, 0x28), // n_divider
<sb0>
+ (0x3, 0x30), // n_divider
<sb0>
why?
<sb0>
oh changing the output frequency from 1GHz to 1.2GHz?
<sb0>
dac clock: 600MHz (div=1) << shouldn't that be div=2 then?
<sb0>
_florent_, there are still intermittent freezes at bridge init.
<sb0>
_florent_, in fact, it fails all the time on sayma1 now ...
<sb0>
anyway, supporting only 1 file (the runtime) and booting right after it is uploaded should be fine. i don't think anyone plays with linux anymore.
<sb0>
okay now on sayma1 the bridge init passes, but hmc830 lock times out ...
<sb0>
well it passes _intermittently_, of course
<sb0>
jesus what a mess
<GitHub126>
[misoc] whitequark pushed 1 new commit to master: https://git.io/vbv9X
<GitHub126>
misoc/master a4d9228 whitequark: microudp: adapt for changes in liteeth core.
<sb0>
whitequark, just talked to the Maryland folks on the phone: their opinion is the SLIP workaround is not interesting and the focus should be on Ethernet
Ultrasauce has quit [Remote host closed the connection]
rjo has quit [Ping timeout: 268 seconds]
<whitequark>
sb0: ack
<whitequark>
sb0: I think I know how to fix Ethernet
<whitequark>
sb0: what's the possible values of dw in liteeth?
<sb0>
8
<whitequark>
that's it?
<sb0>
yes
<whitequark>
why even bother parameterizing then...
<sb0>
I agree...
<whitequark>
I want to rip it out because it makes fixing the preamble checker inconvenient
<whitequark>
ACK?
<whitequark>
hm, wait
<whitequark>
if dw < phy.dw:
<whitequark>
raise ValueError("Core data width({}) must be larger than PHY data width({})".format(dw, phy.dw))
<whitequark>
but... all our PHYs have dw=8
<whitequark>
ok whatever
Ultrasauce has joined #m-labs
<key2>
where can i find an example of programming a flash with openocd ?
<GitHub112>
[artiq] whitequark commented on issue #837: @sbourdeauducq If there is jitter of 1 octet at the beginning of the preamble that will also do the job. And it looks from my experiments like there's a probability of 4/5 that the preamble is not recognized. https://github.com/m-labs/artiq/issues/837#issuecomment-347281126
rohitksingh has quit [Quit: Leaving.]
<FelixVi>
key2: I'd use xc3sprog (I find that easier to use) - xc3sprog -c ftdi -R -I<bscan_file> <path>/top.bit:w:0x0:BIT <path>/bios.bin:w:0x<addr>:BIN
<FelixVi>
ftdi is *most likely* the right cable for what you want to do
<key2>
sure
<key2>
but i need to do it in 2 steps
<key2>
first bscan
<key2>
then bios.bin..
<FelixVi>
my command does it in one shot
<FelixVi>
but you can do it in 2 steps
<FelixVi>
the -I<bscan> part uploads the bscan, then proceeds to upload the bit and bin files
<FelixVi>
-R makes it reset the FPGA, so the new image is loaded
<FelixVi>
so you most likely want - xc3sprog -c ftdi -R -I<bscan_file> <path>/bios.bin:w:BIN
<FelixVi>
this will upload your bios to flash address 0, using the bscan file and then reset
<GitHub189>
[artiq] cjbe commented on pull request #855 3578395: I assume this is what you were looking for? Client() tidies up after itself if it has an exception, so the only logic that needs guarding seems to be the RPC. https://github.com/m-labs/artiq/pull/855#discussion_r153337383