Hello Chris and Rohini,
I have returned and catching the emails flow.
But please, consider that for some architectures it is critical
to have MMU table runtime alterable.
I.e. on RPi the actual memory division to cacheable
and peripheral area is know only at runtime. It depends
on user provided content of configuration files on SDcard
and actual boot loader and VideoCore firmware located
on the SDcard.
On the other hand there could exist even ARM systems
where linker script defined
bsp_translation_table_base = ORIGIN (RAM_MMU)
can be precomputed at compile time and reside in Flash.
But for sure, hardcoding of CP15 setup over all platforms
is incorrect way to go.
As for description how to configure fill the translation table,
i.e.
const arm_cp15_start_section_config arm_cp15_start_mmu_config_table[] = {
I do not think that it has to be global and it would be even
better if its type is not declared in
c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
because then it can be much easier declared as const on
options.
BSP_START_DATA_SECTION extern const arm_cp15_start_section_config
arm_cp15_start_mmu_config_table[];
On the other hand it has quite complex attributes and placement
requirements to be available before memory and workspace
setup, so the global define which enforces these is the best
solution.
We need, for sure, to be able to modify entries in the translation
table at runtime at least during startup phase. When PCI/PCIe becomes
more widespread in embedded/ARM systems then it starts to be even
important because then drivers which find a and map device PCI BARs
into memory space have to select right access and cache variants
according to the device and CPU characteristic. On the other hand,
more new SoC from Ti and FreeScale have option to switch busses
not only to be cache coherent between multiple CPU cores but even
for all/some subset of peripherals. Then even many peripheral
regions can be setup as cached on such systems without need
of special flush, invalidate cache operation before DMA/peripheral
coprocessor data passing.
So please, take in consideration these scenarios.
Making definitions as globals and use of these directly
without passing as parameters of initialization functions
make me worry.
May be some other layering and rearrangement could be better
but static and dynamic (BSP code cotrolled) use options needs
to be provided.
Best wishes,
Pavel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
