<sb0>
whitequark, your misoc makefile changes have broken compatibility, release-3 doesn't build anymore with the error "Makefile:18: *** target file 'all' has both : and :: entries. Stop."
<sb0>
we can stay on the old misoc in release-3 (and backport the spi bugfix), update the release-3 makefiles, or keep compatibility in misoc
mumptai_ has joined #m-labs
mumptai has quit [Ping timeout: 265 seconds]
luozijun has joined #m-labs
luozijun has quit [Ping timeout: 240 seconds]
luozijun has joined #m-labs
luozijun has quit [Remote host closed the connection]
<GitHub89>
[smoltcp] whitequark commented on pull request #110 ae9f28a: Please let's not hassle with this. `pub struct Timestamp { millis: u64 }` is *more than enough*, we are using it right now for a reason. Nanoseconds are completely unnecessary in a TCP/IP stack and calculations with them are a waste of time, and the additional API complexity is a nightmare. https://github.com/m-labs/smoltcp/pull/110#discussion_r15902
_whitelogger has joined #m-labs
<whitequark>
luozijun: hi
<whitequark>
sb0: just do s/all:/all::/
<whitequark>
letme do it I guess
<whitequark>
luozijun: hi
<luozijun>
@whitequark can i speak chinese here ?
<whitequark>
luozijun: you can but I don't think there is anyone who understands chinese in the channel
<whitequark>
except rqou maybe
<whitequark>
all smoltcp developers speak primarily english
<luozijun>
okay :)
<luozijun>
macos loopback interface has same checksum offload problem ?
<whitequark>
I don't know
<whitequark>
I don't work with macos often, I never touched its networking
<whitequark>
what is the checksum? can you print it with tcpdump/wireshark?
<luozijun>
raw packet tcp checksum.
<whitequark>
I mean, what is the value? if it's always 0 then it is checksum offload.
<luozijun>
oh, wireshark's gui is ugly on macos ...
<luozijun>
@whitequark i will check later.
<sb0>
whitequark, what was the idea behind the ::?
<whitequark>
sb0: move .PHONY into common.mak, kill $(ALL_TARGETS) and instead do things like ifeq (...) all:: endif
<sb0>
whitequark, isn't it simpler/cleaner to modify the release-3 makefiles? you said you wanted clean makefiles.
<whitequark>
yes, that's what I want to do
<whitequark>
my previous message was an explanation for ::
<GitHub80>
compiler-builtins/artiq 71bc7b5 whitequark: comparesf2/comparedf2: use i32 instead of bool for return type....
<GitHub80>
compiler-builtins/artiq 1c765ad whitequark: comparesf2/comparedf2: fix a signedness bug and add tests.
<GitHub80>
compiler-builtins/artiq ba8ea23 whitequark: comparesf2/comparedf2: do not build the C versions of intrinsics.
AceChen has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
<sb0>
whitequark, what is this compiler-builtin stuff?
<sb0>
did you write the code in those last commits or does it come from somewhere else?
<rjo>
sb0: could you look at the a7 ddr phy? (bios/sdram.c:(.text.sdrwlon+0x40): undefined reference to `ddrphy_wlevel_en_write')
<sb0>
rjo, what is the litex code there?
<rjo>
sb0: i don't know
<sb0>
what is happening is simply that the a7ddrphy core doesn't have the ddrphy_wlevel_en CSR
<sb0>
_florent_ developed some other technique for write timing...
<sb0>
iirc the corresponding part in the bios should be skipped, and then there is manual adjustement of the PLL phase
<sb0>
probably annoying trial-and-error
<sb0>
there is only one SDRAM chip, so write leveling isn't really needed
<rjo>
could you give it a shot? i am reluctant to touch the preprocessor gymnastics and have little experience with sdram.
<sb0>
I need a kasli
<sb0>
can be remote
<rjo>
exactly. will be sb@murray.ber.quartiq.de
<sb0>
are they shipping one to HK anyway?
<sb0>
rjo, btw the hmc830 is locking again (may or may not be thanks to the spi fix)
<sb0>
but RF output stays at 0
<rjo>
sb0: and jesd works (prbs etc)?
<rjo>
and what do you mean by "RF output"?
<sb0>
scope on allaki output
<sb0>
prbs is waiting on _florent_
<rjo>
kasli is at /dev/serial/by-path/pci-0000:00:14.0-usb-0:8:1.[0123]-port0
<sb0>
you received it already?
<rjo>
sure
<rjo>
i don't know about the one to hk
<sb0>
well then they didn't ship it I suppose
<sb0>
whitequark, how does one load firmware with that new bootloader of yours?
<sb0>
can it be done without artiq_devtool?
<sb0>
whitequark, also, there should be an easy way to erase the runtime from the flash...
<sb0>
or some other mechanism to access network firmware download easily. and you are certainly aware that ethernet on sayma is a total shit-show so we need to load through some other means for now.
<rjo>
sb0: if you want to try 1000base-x, sfp0 is connected to the switch.
<sb0>
ah, the drtio transceivers on sayma begin to communicate. the cpll is locking now for some reason
<sb0>
_florent_, which vivado version are you using?
<sb0>
rjo, do you want to look into the sayma problems? maybe implement prbs?
<sb0>
rjo, what is the command for getting scope screenshots again?
<_florent_>
sb0: i'm probably using the last version of vivado, don't remember the number
<_florent_>
sb0: for cpll that is locking or not, since we are using clocks generated by rtm for drtio, we need the clocking chain to be working (hmc830, hmc7043), so maybe the hmc830 that is now locking can explain that?
<_florent_>
sb0: for dram on artix7, you will indeed need manual adjustment for write, you can probably reuse the same parameters i used (i got them working on several boards).
<_florent_>
sb0: for the rest, it's similar to kintex7
<rjo>
sb0: i'll look at it.
<rjo>
sb0: ds1054z save-screen 192.168.1.132
wingdu has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 240 seconds]
<sb0>
_florent_, no, I'm clocking the transceiver from the Si5324 to get the RTM out of the equation
<_florent_>
sb0: ok
<sb0>
it looks like the vivado trash is misbehaving, whether the cpll locks or not seems to depend on what is connected to its output. trying to confirm that...
<sb0>
_florent_, btw one way to break serwb is to start artiq, then reload the amc fpga without reloading the rtm fpga
<sb0>
this is 100% reproducible AFAICT
<_florent_>
sb0: ok, only on sayma1 or on all boards (because i don't remember having this behaviour)
<sb0>
trying on sayma1 right now
wingdu has quit [Quit: wingdu]
<_florent_>
ok, the amc should reset the rtm on startup, so yes something is miss behaving
wingdu has joined #m-labs
<rjo>
sb0: did you check your rtio channel numbers?
<sb0>
rjo, going through this sort of thing right now, but now the DACs won't initialize. I typically get "bad SYNC" on at least one of them
<rjo>
then there is no point in looking at the outputs yet.
<sb0>
well they initialized before ...
<rjo>
then i'll check the higher layers around sawg and you and _florent_ work on the jesd bootstrap. ok?
<sb0>
retrying the intialization seems to end up suceeding
<sb0>
after 4-5 attempts
<sb0>
(in firmware)
<sb0>
could be this long-standing bug that we also had on kc705
<sb0>
rjo, the ds1054 program just freezes
<rjo>
sb0: as you know, the scope tends to crash. and the program is badly written.
<_florent_>
sb0: so to have ddr working on kasli, i think the only thing you need to do is create a sys4x_dqs clock with 90°phase shift (validated on several design with 100MHz cpu/DDR800
<GitHub106>
[artiq] cjbe commented on issue #865: @whitequark I have not been able to reproduce this problem, even with the gateware version that I originally observed it on. It is possible that it only happens after the KC705 or switch has been power-cycled - I will test this next week when I will have physical access to the hardware again. https://github.com/m-labs/artiq/issues/865#issuecomment-354467978
wingdu has quit [Quit: wingdu]
luozijun has quit []
<sb0>
now the cool new problem: I need at least two sayma boards working for drtio, but at each power-cycle, 1V8 fails on at least one of them
wingdu has joined #m-labs
<rjo>
sb0: kasli with-etherner: software/libnet/microudp.c:(.text.eth_init+0x8): undefined reference to `ethphy_crg_reset_write'
<sb0>
remove that reset
<sb0>
basically, remove the entire eth_init function
<sb0>
so I'm sending 150MHz from the Si5324, and the output seems correct (at least it is correct on the other Si5324 output that goes to the FPGA fabric on Sayma)
<sb0>
I have CPLL_FBDIV=5, CPLL_FBDIV_45=4, CPLL_REFCLK_DIV=1, RXOUT_DIV=2, TXOUT_DIV=2
<sb0>
CPLLREFCLKSEL=0b001
<sb0>
and I have GTREFCLK0 connected to the 150MHz input through a IBUFDS_GTE3, using the O output and CEB=0
<sb0>
iirc I can also put a BUFG in addition to the GTREFCLK0 at the output of the IBUFDS_GTE3, so I'll try that and double-check that the FPGA receives the Si clock correctly
<sb0>
maybe the ltc6957 clock buffer is acting up, idk if Greg tested that
<whitequark>
sb0: you can't do it right now via the bootloader, I am working on it
<whitequark>
same about accessing the netboot mode directly
<whitequark>
however, you can still easily load the firmware via artiq_devtool right now, do `artiq_devtool build hotswap` or `artiq_coreboot hotswap runtime.bin` if you don't want to use devtool
<whitequark>
assuming a working firmware is there in the flash
<whitequark>
I'll get it fixed in a day or so
<whitequark>
sb0: regarding compiler-builtins, I wrote that code
<whitequark>
compiler-builtins is the Rust reimplementation of libcompiler
<whitequark>
libcompiler-rt as well as stdlib functions like memset, memcpy, etc that LLVM will emit itself
<whitequark>
it was missing a single builtin (soft-float comparison) so I wrote that, and now we have one less C dependency...