09:22 <_florent_> david-sawatzke[m: Thanks for the feedback, it indeed seems there is something wrong in https://github.com/enjoy-digital/litex/pull/965, I'm looking at this

12:30 <_florent_> david-sawatzke[m: The regression should be fixed with https://github.com/enjoy-digital/litex/commit/1ce48a973b13ab6e0434408265133bcfc28fbdbb

12:41 <david-sawatzke[m> florent: Thanks for the quick fix, clock constraints seem to work fine now!

17:54 <tnt> I'm a bit confused by linux-on-litex memory layout. I see references to both 0x40000000 and 0xc0000000 as being the base of RAM ? So which is it ?

18:14 <zyp> litex defaults to 0x40000000: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_core.py#L58

18:22 <lambda> I seem to remember some kind of memory space mirroring at one point, that may be long outdated though

18:22 <gatecat> yeah, you aren't wrong, at one point the MSB was being used to determine cached/uncached access

18:23 <gatecat> I don't know if that still applies, either

18:58 <cr1901> Still necessary for CSR space to be uncached

18:58 <zyp> I think upper half of memory space is still uncached, but I'm not sure there's any aliasing

18:59 <tnt> mwell seemed to think this was physical / logical ?

19:08 <cr1901> Ohh hmmm... I've never really used LiteX w/ MMU. That's reasonable... it would be like how MIPS works

19:09 <cr1901> (each 1GB has a different "property" when being accessed, of {cached, not cached} x {MMU, not MMU}

19:53 <tnt> How is the device tree generated for the non-smp case ? The litex_json2dts.py only seem to support SMP ?

19:58 <gatecat> is there any hope reverting to before this commit https://github.com/enjoy-digital/litex/commit/df92e2aea70e680625e699458f9c758cfc919d5c#diff-6bac543d87df6681b46e337de366d43284e9d06de14e43108fe407fb29c4c69f ?

19:59 <tnt> You mean litex dropped non-smp linux support all together ?

20:00 <gatecat> I get the feeling, but tbh I haven't followed litex linux stuff enough to definitively comment

20:54 <_florent_> tnt: We indeed dropped the non-smp support for Linux-on-LiteX-Vexriscv to simplify things. Charles tried to optimize the 1 CPU version to be almost equivalent in term of resources to the previous non-smp vexriscv.

20:57 <_florent_> for the memory space mirroring, it's no longer present, but vexriscv-smp uses specific mapping: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv_smp/core.py#L136-L144

23:02 <cr1901> Why was the memory space mirrored in the first place?

23:05 <cr1901> Any new bug is likely an indication your design is less wrong than before :)

23:18 <cr1901> _florent_: Why does vecriscv define UART_POLLING? https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv_smp/core.py#L151