*** tpb <[email protected]> has joined #litex | 00:00 | |
*** Degi_ <[email protected]> has joined #litex | 01:27 | |
*** Degi <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 01:30 | |
*** Degi_ is now known as Degi | 01:30 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 03:05 | |
*** TMM_ <[email protected]> has joined #litex | 03:05 | |
*** analognoise1 <analognoise1!~analognoi@2600:8801:8c26:9e00:79ca:e8bd:ca52:d723> has joined #litex | 05:50 | |
*** analognoise <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 05:54 | |
*** analognoise <[email protected]> has joined #litex | 06:05 | |
*** analognoise1 <analognoise1!~analognoi@2600:8801:8c26:9e00:79ca:e8bd:ca52:d723> has quit IRC (Ping timeout: 250 seconds) | 06:09 | |
*** futarisIRCcloud <[email protected]> has joined #litex | 06:13 | |
*** michalsieron <[email protected]> has joined #litex | 07:18 | |
*** Melkhior <Melkhior!~Melkhior@2a01:e0a:1b7:12a0:225:90ff:fefb:e717> has quit IRC (Quit: Leaving) | 07:27 | |
_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 | 09:22 |
---|---|---|
*** cr19011 <cr19011!~William@2601:8d:8600:911:7c10:167b:ad8e:ebd> has joined #litex | 10:18 | |
*** cr1901 <cr1901!~William@2601:8d:8600:911:e449:f0:e27b:3a3c> has quit IRC (Killed (NickServ (GHOST command used by cr19011!~William@2601:8d:8600:911:7c10:167b:ad8e:ebd))) | 10:18 | |
*** cr19011 is now known as cr1901 | 10:18 | |
*** michalsieron1 <[email protected]> has joined #litex | 12:16 | |
*** michalsieron <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 12:17 | |
*** michalsieron1 is now known as michalsieron | 12:17 | |
_florent_ | david-sawatzke[m: The regression should be fixed with https://github.com/enjoy-digital/litex/commit/1ce48a973b13ab6e0434408265133bcfc28fbdbb | 12:30 |
*** chiefwigms <[email protected]> has joined #litex | 12:38 | |
david-sawatzke[m | florent: Thanks for the quick fix, clock constraints seem to work fine now! | 12:41 |
*** cr19011 <cr19011!~William@2601:8d:8600:911:7c10:167b:ad8e:ebd> has joined #litex | 13:20 | |
*** cr1901 <cr1901!~William@2601:8d:8600:911:7c10:167b:ad8e:ebd> has quit IRC (Read error: Connection reset by peer) | 13:20 | |
*** michalsieron <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 15:36 | |
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 15:42 | |
*** TMM_ <[email protected]> has joined #litex | 15:43 | |
*** cr19011 is now known as cr1901 | 17:51 | |
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 ? | 17:54 |
zyp | litex defaults to 0x40000000: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_core.py#L58 | 18:14 |
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:22 |
gatecat | I don't know if that still applies, either | 18:22 |
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:58 |
tnt | mwell seemed to think this was physical / logical ? | 18:59 |
cr1901 | Ohh hmmm... I've never really used LiteX w/ MMU. That's reasonable... it would be like how MIPS works | 19:08 |
cr1901 | (each 1GB has a different "property" when being accessed, of {cached, not cached} x {MMU, not MMU} | 19:09 |
tnt | How is the device tree generated for the non-smp case ? The litex_json2dts.py only seem to support SMP ? | 19:53 |
gatecat | is there any hope reverting to before this commit https://github.com/enjoy-digital/litex/commit/df92e2aea70e680625e699458f9c758cfc919d5c#diff-6bac543d87df6681b46e337de366d43284e9d06de14e43108fe407fb29c4c69f ? | 19:58 |
tnt | You mean litex dropped non-smp linux support all together ? | 19:59 |
gatecat | I get the feeling, but tbh I haven't followed litex linux stuff enough to definitively comment | 20:00 |
_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:54 |
_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 | 20:57 |
cr1901 | Why was the memory space mirrored in the first place? | 23:02 |
* tnt got to panic() ... progress :p | 23:04 | |
cr1901 | Any new bug is likely an indication your design is less wrong than before :) | 23:05 |
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 | 23:18 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!