From: david.brown@hesbynett.no   
      
   On 06/11/2025 14:17, Michael S wrote:   
   > 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.   
      
   Scott is talking about specialised use of an M7 within a Cortex-A SoC   
   that is itself rather specialised (I'm guessing it is embedded within a   
   massive switch chip).  The folks that program it are going to be within   
   the same company as the folks that made the SoC, and it's reasonable to   
   assume they know what they are doing.  I agree that there can be gotchas   
   here that could cause trouble for the average microcontroller programmer.   
      
   > Its   
   > data cache is unaware of tricks you play with windows, so programmer   
   > have to flush/invalidate cache lines manually.   
      
   My guess is that the address range here would be marked uncacheable.   
      
   > Sooner or later   
   > programmer will make mistake. A mistake of the sort that is very hard to   
   > debug.   
      
   I certainly agree that cache issues can be a challenge to debug, and if   
   you don't understand what's going on, you can get very strange effects.   
   Caches are something that you can often ignore when doing "normal"   
   things, but if you are doing something unusual, you have to get the code   
   right by design.  You can't test your way to correct code, or use   
   trial-and-error here!   
      
   > I'd say, if you (SOC designer) absolutely have to play these games, just   
   > use Cortex-M4.   
   >   
      
   It's easy enough to make the memory area in question uncacheable, and   
   then there is no problem.   
      
   (I think it is likely that for the kind of uses such a device would   
   have, such as running memory tests before starting the main system,   
   caching is not helpful.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)