From: already5chosen@yahoo.com
On Thu, 6 Nov 2025 13:56:17 +0100
David Brown wrote:
> On 06/11/2025 12:21, bart wrote:
> > 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.
>
> You were fine up until the last sentence here. What do you mean by
> "cheating" ? Whose rules is it breaking? The system Scott was
> describing (assuming I understood him correctly) let the 32-bit core
> access blocks of the 64-bit address space. You can choose which part
> of the address space is accessible at any given time (presumably by
> accessing segment or window registers like any other memory-mapped
> peripheral registers). But you can't call it "cheating" unless you
> have defined some set of rules for what is "allowed" and what is not
> allowed, and everyone else has agreed to play by those rules.
>
>
Doing this sort of tricks with Cortex-M7 is asking for trouble. Its
data cache is unaware of tricks you play with windows, so programmer
have to flush/invalidate cache lines manually. Sooner or later
programmer will make mistake. A mistake of the sort that is very hard to
debug.
I'd say, if you (SOC designer) absolutely have to play these games, just
use Cortex-M4.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
