You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the Fomu workshop, one of the exercises uses LiteX to create a WishBone bus with peripherals (RAM and RGB LED) but no CPU. This is probably a rare situation that is not much tested. It it part of the reason why we haven't been able to bump litex_boards submodule in the Fomu workshop (im-tomu/fomu-workshop#411).
But now I'm seeing a related issue even with the current submodules. CSRs are supposed to be mapped at 0xE0000000 / 0x60000000 (link), but after the build, they appear at 0x00000000 (see im-tomu/fomu-workshop#509). 0x00000000 should be the ROM region.
I think this behavior originates where the CPU mem_map is merged with the SOC's mem_map:
self.mem_map.update(self.cpu.mem_map) # FIXME
If I print out the SOC mem_map, the CPU mem_map, and then the SOC mem_map after the update, I see:
Thanks for the feedback @tcal-x, I indeed wanted to rework this and at least add the override info to the build log (=full traduction of the FIXME I put some time ago :)).
I just used the Fomu target and should have fixed your issue with ce58649.
The CPUNone case is a bit different than others, so I changed the priority in the remapping for it: User's mapping have the priority in this case.
Please let me know if it fixes the issue on your side (and if you have other blockers preventing you from using upstream LiteX).
In the Fomu workshop, one of the exercises uses LiteX to create a WishBone bus with peripherals (RAM and RGB LED) but no CPU. This is probably a rare situation that is not much tested. It it part of the reason why we haven't been able to bump litex_boards submodule in the Fomu workshop (im-tomu/fomu-workshop#411).
But now I'm seeing a related issue even with the current submodules. CSRs are supposed to be mapped at 0xE0000000 / 0x60000000 (link), but after the build, they appear at 0x00000000 (see im-tomu/fomu-workshop#509). 0x00000000 should be the ROM region.
I think this behavior originates where the CPU mem_map is merged with the SOC's mem_map:
If I print out the SOC mem_map, the CPU mem_map, and then the SOC mem_map after the update, I see:
If I add a guard as below, it prevents the CSR region base from being set to zero, and normal behavior is restored.
Of course, there may be a better fix (such has having an empty mem_map for the CPU when its type is None).
The text was updated successfully, but these errors were encountered: