_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
NotHet has joined #litex
<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?
<NotHet> Ok so I am thinking a lot of the Zephyr LiteX drivers were broken by the switch to the 32 bit CSR bus.
<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
<NotHet> Is setting csr_data_width to 8 a resonable idea for Zypher?
<NotHet> Nope, that doesn't work. Gives an assertion error.
key2 has quit [Read error: Connection reset by peer]
key2 has joined #litex
<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:
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<tcal> `
builder_inferedddrtristate2__i` connects those two SB_IO instances, from(?) one's `PACKAGE_PIN` to the other's `D_IN_0`.
NotHet has quit [Ping timeout: 260 seconds]
nosky has quit [Quit: Client closed]
Degi_ has joined #litex
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
NotHet has joined #litex
NotHet has quit [Ping timeout: 252 seconds]
<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)?
<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.)
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 265 seconds]
NotHet has joined #litex
NotHet has quit [Ping timeout: 260 seconds]
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
<_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).
<_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
<_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
<_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
peeps[zen] has quit [*.net *.split]
Degi has quit [*.net *.split]
TMM_ has quit [*.net *.split]
zjason has quit [*.net *.split]
shorne has quit [*.net *.split]
tpw_rules has quit [*.net *.split]
awordnot has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
peeps[zen] has joined #litex
TMM_ has joined #litex
Degi has joined #litex
RaYmAn has joined #litex
tpw_rules has joined #litex
awordnot has joined #litex
zjason has joined #litex
shorne has joined #litex
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
peepsalot has joined #litex
peeps[zen] has quit [Ping timeout: 252 seconds]
linear_cannon has quit [Ping timeout: 260 seconds]
linear_cannon has joined #litex
Finde has quit [Quit: WeeChat 2.3]
Finde has joined #litex
NotHet has joined #litex
NotHet has quit [Ping timeout: 250 seconds]
NotHet has joined #litex
<acathla> The actual litex wants to use picolibc but fails, how do I force the use of the old libc?
<acathla> Meanwhile, I did a checkout on an old litex (23sept) and it works fine again
<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)
<cr1901> ?
<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.
<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.
<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.
lexano has quit [Quit: Leaving]
NotHet has quit [Ping timeout: 245 seconds]
Melkhior has quit [Remote host closed the connection]
Melkhior has joined #litex
<tnt> Why do some platform do platform.add_period_constraint(self.cd_sys.clk, 1e9/sys_clk_freq) and some don't ?
<tpb> Title: class CRG(Module): def __init__(self, platform, sys_clk_freq): sel - Pastebin.com (at pastebin.com)
<tnt> That's the CRG I'm using ATM but looking at timing report it seems it analyzed nothing ...
<tnt> so I'm guessing I might need it but I thought the USMMCM knowing the input/output freq would deal with that.
FabM has quit [Ping timeout: 260 seconds]
yorick has quit [Quit: brb]
<_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?
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
<_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
<_florent_> tnt: If you input clk has a timing constraint, it should propagate through the PLL/MMCm
<_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
<tnt> _florent_: ok, so I guess that's what I'm missing.
<_florent_> tnt: but yes, it's possible we still have some inconsistencies between platforms/targets on timing constraints
<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 :)
<_florent_> tnt: ah good, this will probably be a bit more accurate than the internal osc :)
<acathla> _florent_, error log here : https://pastebin.com/CzyuxSye
<tpb> Title: Litex and picolibc error - Pastebin.com (at pastebin.com)
<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 :/
<tnt> Err ... how do I include {} in custom plaform commands ? They get interpreted by python at some step in the process ...
<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?
<jevinskie[m]> Add more {}, you really have to throw them in there :)
<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
mntmn has joined #litex
<_florent_> acathla: can you try to install meson with pip3 install meson to have a recent version?
<_florent_> leons: The optical module should operate correctly with just tx_disable set correctly, no extra setup is required
<_florent_> leons: But check the polarity of tx_disable, it's sometimes inverted on the board
<tnt> if the remote sees power, it should be good.
<acathla> _florent_, it works!
<acathla> Thanks. 0.53.2-2ubuntu2 vs 0.59.2
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 252 seconds]
peepsalot has joined #litex
peeps[zen] has quit [Ping timeout: 252 seconds]
<tnt> "Memory initialization failed "
<tnt> Ah well, would have been too good if it works first time :)
FabM has quit [Quit: Leaving]
<tnt> Question is of course: how does one even debug that :/
<tpb> Title: Initializing SDRAM @0x40000000... - Pastebin.com (at pastebin.com)
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
<tnt> Does anyone have a working DDR4 calib just to see what a good one is supposed to look like ?
Guest53 has quit [Ping timeout: 256 seconds]
<_florent_> tnt: have you set the INTERNAL_VREF constraints on the DRAM banks?
<tnt> _florent_: I have not.
<_florent_> This probably explains the behaviur. On DDR4 these constraints a really mandatory.
<tnt> Trying it now.
<_florent_> here is an log of a working calibration:
<tpb> Title: hastebin (at hastebin.com)
<tnt> `Memtest OK` \o/
<tnt> Thanks !
<tnt> And the other ddr4 bank works too. Perfect.
<tnt> I guess the next step is PCIe. I got it to build but it's seemingly doing nothing.
NotHet has joined #litex
NotHet has quit [Ping timeout: 252 seconds]
NotHet has joined #litex
NotHet has quit [Ping timeout: 265 seconds]