We should consider how to continue making improvements in this area of RTEMS.
On Mon, Aug 24, 2015 at 1:25 PM, Rohini Kulkarni <krohini1...@gmail.com> wrote:
> 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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
