02:53 <gregdavill> _florent_: Weird that I'd never seen this startup behaviour happening before.

02:54 <gregdavill> I've got a test setup here, if the memtest passes it reboots. If it fails it will spin-wait.

02:55 <gregdavill> Following the advice from Lattice notes, I've altered the init clock domain (also por) to be sourced from the internal OSCG. Results look good so far.

02:56 <gregdavill> I've run through ~100 test/reboot cycles without failing. But my tree is dirty. Later I'll need to sync everything up and validate again.

03:11 <futarisIRCcloud> benh: https://github.com/antonblanchard/microwatt/commits/master - So 16550 UART and liteeth are in master now?

03:11 <tpb> Title: Commits · antonblanchard/microwatt · GitHub (at github.com)

03:13 <benh> futarisIRCcloud: looks like it :-)

03:15 <benh> somlo: I wouldn't expect it to be *that* slow unless it's going through layer for every bit...

03:15 <benh> I am not that familiar with the MMC layer in Linux mind you

03:15 <benh> perf is your friend to measure what's going on

03:19 <benh> the linux SPI MMC driver is ... a bit dumb

03:19 <benh> I would rather write a dedicated MMC driver for litesdcard :)

03:19 <benh> esp if you want to do dual or quad

03:38 <gregdavill> Turns out I'd only changed the POR counter to be running from the OSCG (31MHz). That seems like enough to fix. Weird indeed.

05:11 <_florent_> gregdavill: thanks for looking at this, i also don't remember having this behavior before. I will test your fix and will try to understand

05:14 <gregdavill> If I run init clock domain from the OSCG too, it is not fixed.

05:17 <_florent_> which Lattice note where you following? (just to also have a look)

05:19 <gregdavill> TN-02035: ECP5 High speed I/O interface. In Table 9.3 for the GDDR_SYNC soft IP (Which litedram implements similar function with a timeline)

05:20 <gregdavill> `SYNC_CLK: Startup clock. This cannot be the RX_CLK or divided version. It can be other low speed continuously running clock. For example, oscillator clock`

08:12 <_florent_> gregdavill: the issue seems related to the recent changes i did to the PHY (on the read/write control path + dqs), i'm looking at this

08:45 <gregdavill> Maybe timing related? I've been able to run the same json-netlist through nextpnr with different seeds. One resulting bitstream works, another fails. (Or maybe I've hit a different bug :/ )

14:49 <_florent_> gregdavill: this should now be working. The issue is that the calibration can required different bitslip value between initialization and the changes i did on the Bitslip module was preventing it. I did a couple of others fix on things i wanted to investigate and also update the boards in litex-boards.

14:50 <_florent_> i did a test on the 1GB OrangeCrab variant (at 96MHz since i still need to look at https://github.com/enjoy-digital/litedram/issues/130)

14:50 <tpb> Title: ECP5: CL settings behaviour · Issue #130 · enjoy-digital/litedram · GitHub (at github.com)

14:54 <_florent_> next time i look at this i'll try to understand why we have a different Bitslip results between initilializations (we should be able have consistent results), but enough of this for today :)

16:58 <scanakci> _florent_: I made the PR (https://github.com/litex-hub/pythondata-auto/pull/3). Please let me know if anything is missing.

16:58 <tpb> Title: Update BP main repo website by scanakci · Pull Request #3 · litex-hub/pythondata-auto · GitHub (at github.com)

18:17 <satnav> Can someone please advice me about the CSR bus and Wishbone bus in aspect for example of connecting UART core to SoC? I mean, what's the difference between make the UART core as wishbone slave and in the UART core code add CSR with wishbone2csr bridge. vs, just add UART as CSR to soc's CSR bus.

18:29 <somlo> satnav: the CSR bus is LiteX's way to auto-allocate MMIO addresses and auto-generate accessor methods for LiteX's own devices (part of the ecosystem, written in migen, hosted in one of the lite* projects on github under either enjoy-digital or litex-hub, etc.

18:30 <somlo> If you have your own UART (with a wishbone interface already exposed), then probably hooking it directly into the wishbone bus would make more sense

18:32 <satnav> How I will interact with the UART core and CPU in aspect of registers? Should I use CSR?

18:33 <satnav> Bottom line, I try to understand how should I expose registers with wishbone slave core

18:34 <somlo> satnav: if you are using the UART included with LiteX, it's already being generated to use CSR out of the box. If for some reason you have your own non-LiteX UART IP block, then you'll have to write some glue logic in migen to "connect" it to LiteX. In *that* case, it depends on what your IP block exposes in terms of an interface

18:39 <satnav> thanks a lot for the informative answers somlo

18:47 <satnav> Just to make sure that I understood correctly, according to the example here - https://github.com/enjoy-digital/litex/blob/master/litex/boards/targets/simple.py the LittleEthPHY added as slave to the wishbonebus and also added to the CSR bus? are they separated buses? also, can I make a SoC without wishbone bus at all, just CSR bus?

18:47 <tpb> Title: litex/simple.py at master · enjoy-digital/litex · GitHub (at github.com)

19:48 <somlo> satnav: LiteETH has a more complex interface -- there's the phy (exposed as CSR mmio registers), there's the ethmac region (basically memory for tx/rx buffers), and an interrupt. But yeah, the configuration registers are set up as CSRs via that example you pointed out

19:51 <satnav> thanks somlo!