From: bc@freeuk.com
On 06/11/2025 07:51, David Brown wrote:
> On 05/11/2025 16:15, Scott Lurndal wrote:
>> David Brown writes:
>>> On 04/11/2025 23:04, Scott Lurndal wrote:
>>>> David Brown writes:
>>>>> On 04/11/2025 18:32, Scott Lurndal wrote:
>>>>
>>>>> . (And I have never
>>>>> seen a Cortex-M device with programmable windows or addresses -
>>>>> indeed,
>>>>> I believe the Cortex-M core documentation specifies some memory ranges
>>>>> explicitly.
>>>>
>>>> I have used Cortex-M devices with programmable windows
>>>> in the physical address space.
>>>
>>> OK. I have not, but I haven't used the newer Cortex-M cores as yet, so
>>> it could well be a new feature.
>>
>> It is not necessarily a feature of the M7 core itself, but rather
>> the glue logic around it - particularly the logic that interfaces
>> to the "system bus" to which the M7 core is interfaced. That logic
>> is under the control of the SoC designer and can easily have
>> external registers that are programmed to specify how to route
>> accesses from the M7, including to large regions of DRAM;
>> consider a maintenance processor on a 64-bit server that needs
>> access to the server DRAM space for RAS purposes.
>>
>
> Fair enough, now I see what you are getting at. Yes, once you are
> outside the Cortex-M core and key ARM-supplied components (like the
> interrupt controller), you as a SoC designer are free to do what you
> like. And if you have a 32-bit processor that needs access to a 64-bit
> address space, you are going to have to do some kind of windowing or
> segmenting.
>
> In the SoC's I have used where 64-bit Cortex-A processors are combined
> with a Cortex-M core for security purposes, booting, or for better real-
> time control of peripherals, the Cortex-M device does not have direct
> access to the 64-bit memory space. It has access to the peripherals,
> some dedicated memory, and a message-passing interface with the Cortex-A
> cores.
>
> But in your work, you probably see more variety and more possibilities
> for these things - I only get to use the chips someone else has made!
>
I think you were right, if this 'M7' chip doesn't directly have
registers, instructions or infrastructure to access the more complex
memory system.
Unless you are modifying M7 itself, then that 'glue' logic could be
applied to anything (eg. I've built a Z80 system with 256KB RAM), and it
is that composite system that a language + compiler can target.
Then it would appear to the use of the language that the target machine
had those extended features. But if they were to look at the generated
code, they might see it was accessing external registers or whatever.
So it's cheating.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
