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.
But then is such refactoring a good idea? These changes even if modified
will apply only to cp15 ARM BSPs.
On 24 Aug 2015 21:20, "Pavel Pisa" <p...@cmp.felk.cvut.cz> wrote:
> 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
