Re: Platform memory map
toggle quoted message Show quoted text
Yes absolutely. I wrote an RV32 MCU question to the unix platform spec group which is my bad.
On Sat, Jun 6, 2020 at 8:58 AM Andrew Waterman <andrew@...> wrote:
I just want to say unequivocally that trying to emulate the Cortex-M memory map in the Unix platform is a short-sighted idea that will only cause extra trouble.These platforms aren’t compatible anyway. You can’t run Linux on a Cortex-M. Cortex-A memory maps don’t look like Cortex-M memory maps, for good reason.On Fri, Jun 5, 2020 at 3:45 PM Nagendra Gulur <nagendra.gd@...> wrote:I joined the group recently and not sure that I have all the context yet for what the group's charter and current scope are.
However, I was exchanging email with Andrew Waterman about RV32 cores and system integration standardization.
Specifically, I was wondering where the mtime and mtimecmp registers were memory-mapped per the privileged spec.
And the answer is that this is a platform-level decision and not in the scope of the privileged spec.
Next, I took a brief look at the documentations from SiFive and ETH/Pulp for RV32-based SoCs.
Their SoC-level memory maps are completely different. Neither is compatible with ARM CxM either.
These differences start to matter if we want to establish more standard ways to assemble SoCs, use standard debug/link tools (such as IAR or Lauterbach for example), or to develop consistent boot loader modules and so on.
It would be quite useful to bring some attention to this problem of SoC-level fragmentation.
At a high level, on the memory mapping topic, one might provide a broad specification of where on-chip memories go, where flash/nvm goes, and peripheral spaces, etc.
My apologies if this is a repetition of what has already been discussed before.