Anonymous user
ARM Overview: Difference between revisions
m
→Memory Detection
| [unchecked revision] | [unchecked revision] |
m (Not really a stub anymore) |
|||
Line 252:
Memory detection is much different if you are coming from a background in the X86/X64 architecture. The ARM cores are used in many embedded applications and therefore the system board which the core resides on does not need to be overly complicated in order to be compatible with others boards. This is because almost any production board with an ARM core on it was likely custom designed just for that purpose. It is quite possible to use some generic board, but for lots of embedded applications there may not even be an operating system.
Therefore memory detection mechanisms may be non-existent and instead your operating system may opt for a value to be encoded into it at compile for for a specific system (board) which is known to have a certain amount of memory, or you may have a specific driver that your operating system loads just for that board (or is compiled in) where the driver can be queried by your kernel for the amount of memory installed. There are lots of ways and these were just two ideas, but the important part is to understand that unlike the X86/X64 compatible systems you will likely find absolutely no mechanisms to ''properly'' poll the amount of memory.
It may however be possible to probe memory and recover using processor exceptions. This still may not provide information about if a region of memory is FLASH, memory-mapped I/O, RAM, or ROM depending on how the system board was designed as I do suspect it could be quite possible for some ROM to be external to the core and allow writes to silently fail, and this coupled with the possibility of a region of memory to need a special unlock sequence in order to write to it will render your memory auto-detection code into a potential corner-case.
| |||