00:20 <tcal> Am I naive for hoping that I could get DDR litespi running on a Fomu by just adding "rate='1:2'" to `self.add_spi_flash(....)` in litex_boards/targets/kosagi_fomu.py?

00:36 <NotHet> Ok so I am thinking a lot of the Zephyr LiteX drivers were broken by the switch to the 32 bit CSR bus.

00:37 <NotHet> Needing partial re-writes: hwinfo_litex.c, eth_liteeth.c, litex_timer.c; Ok if soc/riscv/litex/soc.h were fixed: gpio_litex.c, i2c_litex.c, i2s_litex.c, pwm_litex.c, uart_liteuart.c; not sure clock_control_litex.c

00:59 <NotHet> Is setting csr_data_width to 8 a resonable idea for Zypher?

01:28 <NotHet> Nope, that doesn't work. Gives an assertion error.

01:46 <tcal> DDR on Fomu doesn't work out of the box by just adding `rate='1:2'`; the error message is `ERROR: Unable to find a placement location for cell 'SB_IO_13'`. This is the IO structure that's generated:

01:46 <tcal> https://www.irccloud.com/pastebin/VEo8LxW6/fomu%20ddr%20io

01:46 <tpb> Title: Snippet | IRCCloud (at www.irccloud.com)

01:48 <tcal> `
builder_inferedddrtristate2__i` connects those two SB_IO instances, from(?) one's `PACKAGE_PIN` to the other's `D_IN_0`.

04:43 <cr1901> _florent_: I'm going to ask a question, and you're not going to like it :). Since it appears we now have a dep on meson thanks to picolibc, are there any potential plans to rip out the Makefile completely and use meson to build all the software :) (and maybe even the gateware :o)?

04:46 <cr1901> (This is not an entirely serious suggestion, btw. But I'm probably going to do a round of Windoze compat patches soon, and it was on my mind.)

06:40 <_florent_> cr1901: This could be worth having a look at it in the long term yes (but using Makefile is also nice to simplify integration with other software relying on it, ex MicroPython).

06:41 <_florent_> NoHet: I thought Zephyr drivers were already using 32-bit CSRs, if it's not the case, it would be interesting to do the switch as we did in the Linux drivers

07:14 <_florent_> NoHet: I just verified and the recent LiteEth changes do not introduce a CSR mapping change. So the issue in Zephyr seems to be only related to the CSR data-width

07:15 <_florent_> Note that you the default has changed in LiteX, but you can still pass --csr-data-width=8 to use 8-bit CSR data-width SoCs

13:10 <acathla> The actual litex wants to use picolibc but fails, how do I force the use of the old libc?

13:19 <acathla> Meanwhile, I did a checkout on an old litex (23sept) and it works fine again

13:38 <cr1901> I know riscv and power get most of the love lately, but is there a way to ensure e.g. a lm32 SoC still builds (picolibc doesn't support lm32 yet)

13:38 <cr1901> ?

13:53 <NotHet> _florent_: Looks like 8 bit CSR was/is broken? https://github.com/enjoy-digital/litex/commit/4ee9c53f185ac6dd9c4aa69a7547e9bc037acc25 . Removing the assert the SOC will build, but the bios hangs in spiflash_core_master_status_rx_ready_read.

13:53 <NotHet> I am thinking I will try to fix Zephyr drivers for 32 bit CSR. Probably two weeks+ to complete. I am most worried about test, I have a single HW platform with limited peripherals.

13:53 <NotHet> Having someone I can bother with questions about the drivers would be good too, is there someone willing? I see most drivers are authored by AntMicro.

14:24 <tnt> Why do some platform do platform.add_period_constraint(self.cd_sys.clk, 1e9/sys_clk_freq) and some don't ?

14:24 <tnt> https://pastebin.com/6Trat0Cr

14:24 <tpb> Title: class CRG(Module): def __init__(self, platform, sys_clk_freq): sel - Pastebin.com (at pastebin.com)

14:24 <tnt> That's the CRG I'm using ATM but looking at timing report it seems it analyzed nothing ...

14:25 <tnt> so I'm guessing I might need it but I thought the USMMCM knowing the input/output freq would deal with that.

14:55 <_florent_> acathla, cr1901: All the different supported CPU have been tested with picolibc (this was a condition to use it), so it should still work, if not can you describe the issue?

14:57 <_florent_> NoHet: The Zephyr drivers are indeed maintained by Antmicro, could you open an issue in LiteX to describe the issues? and I'll make sure you can discuss with them

14:58 <_florent_> tnt: If you input clk has a timing constraint, it should propagate through the PLL/MMCm

15:00 <_florent_> tnt: you can do something similar to https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/xilinx_kc705.py#L551 in your Platform

15:00 <tnt> _florent_: ok, so I guess that's what I'm missing.

15:01 <_florent_> tnt: but yes, it's possible we still have some inconsistencies between platforms/targets on timing constraints

15:01 <tnt> _florent_: btw, I found a working clock on that board ... there is an ad9542 which is also a programmable pll but it's configured to auto-load its config from an i2c eeprom :)

15:03 <_florent_> tnt: ah good, this will probably be a bit more accurate than the internal osc :)

15:09 <acathla> _florent_, error log here : https://pastebin.com/CzyuxSye

15:09 <tpb> Title: Litex and picolibc error - Pastebin.com (at pastebin.com)

15:22 <tnt> Mmm, I was hoping platform.add_false_path_constraints(self.crg.cd_sys.clk, self.pcie_phy.cd_pcie.clk) would do the trick, but it's still analysin across :/

15:46 <tnt> Err ... how do I include {} in custom plaform commands ? They get interpreted by python at some step in the process ...

15:55 <leons> florent: I've seen on your twitter that you have gotten SPF+ modules working with the FPGAs. Do you by chance know whether there's any extra setup required (besides deasserting the TX_DISABLE pin) compared to using DACs?

15:55 <jevinskie[m]> Add more {}, you really have to throw them in there :)

15:55 <leons> On my FPGA I have 10G Ethernet working using a DAC just fine, but on optical modules I don't get a carrier. My other device does indicate some receive signal power though

16:42 <_florent_> acathla: can you try to install meson with pip3 install meson to have a recent version?

16:47 <_florent_> leons: The optical module should operate correctly with just tx_disable set correctly, no extra setup is required

16:48 <_florent_> leons: But check the polarity of tx_disable, it's sometimes inverted on the board

16:48 <tnt> if the remote sees power, it should be good.

16:48 <acathla> _florent_, it works!

16:59 <acathla> Thanks. 0.53.2-2ubuntu2 vs 0.59.2

17:57 <tnt> "Memory initialization failed "

17:57 <tnt> Ah well, would have been too good if it works first time :)

18:04 <tnt> Question is of course: how does one even debug that :/

18:05 <tnt> https://pastebin.com/j5DZtGhE

18:05 <tpb> Title: Initializing SDRAM @0x40000000... - Pastebin.com (at pastebin.com)

19:11 <tnt> Does anyone have a working DDR4 calib just to see what a good one is supposed to look like ?

20:21 <_florent_> tnt: have you set the INTERNAL_VREF constraints on the DRAM banks?

20:21 <_florent_> ex: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/xilinx_zcu104.py#L121-L123

20:24 <tnt> _florent_: I have not.

20:25 <_florent_> This probably explains the behaviur. On DDR4 these constraints a really mandatory.

20:27 <tnt> Trying it now.

20:27 <_florent_> here is an log of a working calibration:

20:27 <_florent_> https://hastebin.com/foradezoha.yaml

20:27 <tpb> Title: hastebin (at hastebin.com)

20:32 <tnt> `Memtest OK` \o/

20:32 <tnt> Thanks !

20:41 <tnt> And the other ddr4 bank works too. Perfect.

20:41 <tnt> I guess the next step is PCIe. I got it to build but it's seemingly doing nothing.