| openpowerbot | [slack] <Matt Johnston> I'm seeing strange load/store behaviour here. to a DRAM address, | 07:39 |
|---|---|---|
| openpowerbot | [slack] <Matt Johnston> ```li %r8, 0x45 # value1 to store | 07:39 |
| openpowerbot | [slack] <Matt Johnston> stb %r8,0(%r30) | 07:39 |
| openpowerbot | [slack] <Matt Johnston> lbz %r10,0(%r30) | 07:39 |
| openpowerbot | [slack] <Matt Johnston> | 07:39 |
| openpowerbot | [slack] <Matt Johnston> li %r8, 0x89 # value2 to store | 07:39 |
| openpowerbot | [slack] <Matt Johnston> stb %r8,0(%r30) | 07:39 |
| openpowerbot | [slack] <Matt Johnston> lbz %r11,0(%r30)``` | 07:39 |
| openpowerbot | [slack] <Matt Johnston> `r10` ends up with 0x00 (usually, or perhaps 0xff), `r11` ends up with correct 0x89 | 07:39 |
| openpowerbot | [slack] <Matt Johnston> thoughts what could be going wrong? | 07:40 |
| openpowerbot | [slack] <Matt Johnston> I'm seeing strange store/load behaviour here. to a DRAM address, | 07:44 |
| openpowerbot | [slack] <Matt Johnston> ```li %r8, 0x45 # value1 to store | 07:44 |
| openpowerbot | [slack] <Matt Johnston> stb %r8,0(%r30) | 07:44 |
| openpowerbot | [slack] <Matt Johnston> lbz %r10,0(%r30) | 07:44 |
| openpowerbot | [slack] <Matt Johnston> | 07:44 |
| openpowerbot | [slack] <Matt Johnston> li %r8, 0x89 # value2 to store | 07:44 |
| openpowerbot | [slack] <Matt Johnston> stb %r8,0(%r30) | 07:44 |
| openpowerbot | [slack] <Matt Johnston> lbz %r11,0(%r30)``` | 07:44 |
| openpowerbot | [slack] <Matt Johnston> `r10` ends up with 0x00 (usually, or perhaps 0xff), `r11` ends up with correct 0x89 | 07:44 |
| openpowerbot | [slack] <Matt Johnston> it could be to do with the l2 cache layer? it seems to be easier to hit when using new memory addresses, a deep stack etc | 07:51 |
| lkcl | Matt: sim.py in litex _should_ run with pretty much exactly the same config/setup | 20:21 |
| lkcl | i've managed to run hello_world.bin, xics.bin, micropython.bin all successfully under sim.py | 20:21 |
| lkcl | and i thiiink (have a vague recollection, could be wrong) that somewhere someone managed to run the linux initramfs under sim.py as well, although it was... mmm.... 18 months ago? | 20:22 |
| lkcl | if you were to try that, and got the exact same error, it would at least eliminate hardware (FPGA) as the likely source of the problem | 20:23 |
| lkcl | and, also, make it a hell of a lot easier to debug because you could enable GTKwave .vcd/fst output | 20:23 |
| lkcl | and see exactly what the heck was going on | 20:23 |
| lkcl | with ghdl having improved support for records, now, at least the signals will be meaningful, which they weren't before :) | 20:24 |
| lkcl | if that really really doesn't help, at least you can add $display debug prints | 20:24 |
| lkcl | (yes, the simulated DRAM should behave exactly as in FPGA / real-DRAM) | 20:26 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> could be either a core forward/bypass issue, I think Paul might have a path there (@Paul Mackerras rings a bell ?) | 22:42 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> or it could be litedram | 22:42 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> if the core doesn't forward the store to the load, then they will go all the way to litedram | 22:42 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> assuming the L2 is empty at this point for that line, it would put the store in the queue then start loading the line | 22:43 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> litedram is **supposed** to detect the collision | 22:45 |
| openpowerbot | [slack] <Benjamin Herrenschmidt> the l2 has a store queue, so the store would land there first but it will not service load misses until that's empty | 22:45 |
| openpowerbot | [slack] <Paul Mackerras> @Matt Johnston It would be worth checking that you have commit 1a983, which fixed a bug in that general area | 22:47 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!