<p dir="ltr">OK, thanks all for the views. That gave plenty insight into the details I had not thought of earlier. Clearly not the way to go. </p>
<p dir="ltr">But then is such refactoring a good idea? These changes even if modified will apply only to cp15 ARM BSPs.</p>
<div class="gmail_quote">On 24 Aug 2015 21:20, "Pavel Pisa" <<a href="mailto:pisa@cmp.felk.cvut.cz">pisa@cmp.felk.cvut.cz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Chris and Rohini,<br>
<br>
I have returned and catching the emails flow.<br>
<br>
But please, consider that for some architectures it is critical<br>
to have MMU table runtime alterable.<br>
<br>
I.e. on RPi the actual memory division to cacheable<br>
and peripheral area is know only at runtime. It depends<br>
on user provided content of configuration files on SDcard<br>
and actual boot loader and VideoCore firmware located<br>
on the SDcard.<br>
<br>
On the other hand there could exist even ARM systems<br>
where linker script defined<br>
  bsp_translation_table_base = ORIGIN (RAM_MMU)<br>
can be precomputed at compile time and reside in Flash.<br>
<br>
But for sure, hardcoding of CP15 setup over all platforms<br>
is incorrect way to go.<br>
<br>
As for description how to configure fill the translation table,<br>
i.e.<br>
<br>
  const arm_cp15_start_section_config arm_cp15_start_mmu_config_table[] = {<br>
<br>
I do not think that it has to be global and it would be even<br>
better if its type is not declared in<br>
  c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h<br>
because then it can be much easier declared as const on<br>
options.<br>
<br>
 BSP_START_DATA_SECTION extern const arm_cp15_start_section_config<br>
  arm_cp15_start_mmu_config_table[];<br>
<br>
On the other hand it has quite complex attributes and placement<br>
requirements to be available before memory and workspace<br>
setup, so the global define which enforces these is the best<br>
solution.<br>
<br>
We need, for sure, to be able to modify entries in the translation<br>
table at runtime at least during startup phase. When PCI/PCIe becomes<br>
more widespread in embedded/ARM systems then it starts to be even<br>
important because then drivers which find a and map device PCI BARs<br>
into memory space have to select right access and cache variants<br>
according to the device and CPU characteristic. On the other hand,<br>
more new SoC from Ti and FreeScale have option to switch busses<br>
not only to be cache coherent between multiple CPU cores but even<br>
for all/some subset of peripherals. Then even many peripheral<br>
regions can be setup as cached on such systems without need<br>
of special flush, invalidate cache operation before DMA/peripheral<br>
coprocessor data passing.<br>
<br>
So please, take in consideration these scenarios.<br>
<br>
Making definitions as globals and use of these directly<br>
without passing as parameters of initialization functions<br>
make me worry.<br>
<br>
May be some other layering and rearrangement could be better<br>
but static and dynamic (BSP code cotrolled) use options needs<br>
to be provided.<br>
<br>
Best wishes,<br>
<br>
             Pavel<br>
<br>
<br>
</blockquote></div>