User: Password:
Subscribe / Log in / New account

ARM's multiply-mapped memory mess

ARM's multiply-mapped memory mess

Posted Oct 15, 2010 12:53 UTC (Fri) by drag (guest, #31333)
In reply to: ARM's multiply-mapped memory mess by NAR
Parent article: ARM's multiply-mapped memory mess

One of the problems your going to face with ARM is that there is no one single implementation of the hardware, nor all the available hardware now is going to reflect all the hardware that is going to be.

ARM 6 is essentially a specification for a processor and not a real processor. Using the memory in the way the kernel does is 'unspecified'. It could work on today's processors made by Ti, but it could completely backfire on tomorrow's processors made by Marvel.

It's impossible to know and if it does start corrupting memory in the kernel then it's going to be 100% ok as far as the processor designers are concerned because they are still following the specification.

It's similar to having the kernel rely on unspecified GCC features were once a user chooses a GCC version they are forced to use it for ever and cannot change it no matter how badly it works with Linux.

(Log in to post comments)

ARM's multiply-mapped memory mess

Posted Oct 15, 2010 18:34 UTC (Fri) by dlang (subscriber, #313) [Link]

that depsnds on exactly how detailed the specs are. I believe that the ARM specs are not behavior (i.e. must implement these commands these ways), but are instead a much lower level (arrange logic gates in this way)

ARM's multiply-mapped memory mess

Posted Oct 15, 2010 22:17 UTC (Fri) by gnb (subscriber, #5132) [Link]

That in turn depends on the licence: most of their customers (sorry, partners) licence an implementation. They get given either synthesizable code or a hard macro that implements the core (+MMU +cache as appropriate) to drop into their chip. Modulo bugs, all chips of this sort with the same core IP should behave the same. A few large partners (Marvell, Ti?) have architecture licences that cover changing the implementation provided it still matches the spec. . In those cases all bets are off for behaviour that the spec. doesn't define.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds