[rtems commit] bsp/qoriq: Use U-Boot provided FDT

[Chris Johns]

On 22/10/2015 1:09 am, Gedare Bloom wrote:
> On Wed, Oct 21, 2015 at 2:07 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> On 21/10/15 06:15, Chris Johns wrote:
>>>
>>> On 20/10/2015 9:10 pm, Sebastian Huber wrote:
>>>>
>>>> On 20/10/15 00:46, Chris Johns wrote:
> [...]
>>>
>>> It is easy to add things like the FDT support to the shared BSP tree and
>>> if you look over that code we have all sorts of specific localised
>>> things that effect various subsets of BSPs as well as important generic
>>> things almost all BSPs use. The BSP shared directory is becoming more
>>> complex. Changes in that directory tree now effect a wider and wider
>>> range of BSPs and often when things go in it is specific and not a
>>> general API with some level of formal agreement. Add to this testing on
>>> all effected BSPs is often difficult. As I said these things are easy to
>>> add but difficult to remove or change because users end up depending on
>>> them as they are.
>>>
>>> This issue is coming to a head with the build system change.
>>>
>>> If we change or do not provide something in the build system change that
>>> is BSP specific and not an API is it our fault for forcing application
>>> changes or is it the BSP developer's for not providing a formal
>>> interface? What is ok to vary for a BSP and what is not ok?
>>>
>>> As I said easy to add and hard to maintain through changes. We are doing
>>> our best not to change things but it is not easy.
>>
>>
>> Instead of less code in the shared area we need more. There is still a lot
>> of copy and paste in the BSPs. During the interrupt support code cleanup
>> several years ago I removed hundreds of lines of duplicated code.
>>
> I believe Chris' point is that we need more guidance in what should go
> there, and we should aim for more uniformity in the BSP layer to make
> the guidance simple and maintainable. The problem we face is the lack
> of good abstraction within and across BSPs. This is a separate issue
> from the FDT patch itself.

Yes this is correct. Gedare, thanks for nicely expressing this.

> 
>>>
>>>>> I do not remember any discussion about how BSPs and FDT will be
>>>>> supported.
>>>>
>>>> U-Boot supports FDT for several years now. So, all U-Boot based BSPs may
>>>> use this option.
>>>>
>>> FDT is not constrained to u-boot. There are other possible uses in RTEMS.
>>
>>
>> Yes, and for all of the uses a libfdt is probably required.
>>
>> [...]
>>>>>
>>>>> Can you please describe this use of FDT in RTEMS and how this can used
>>>>> by more than the immediate use you have for your BSP?
>>>>
>>>> The use of FDT for BSPs is to get U-Boot provided parameters.
>>>>
>>> Where is this interaction documented and how would a user find this
>>> information?
>>
>>
>> It is documented in the source code and in the README of the BSP.
>>
>> The BSP area of RTEMS is virtually undocumented and even worse the existing
>> documentation is partly outdated and misleading.
>>
> We should try to plan how to correct this problem especially for code
> in the shared part. Doxygen on the source is a good start. README
> files can be hard to find and easy to ignore.
> 

I am also foreshadowing changes in the build system will result in
changes in BSPS and I suspect changes in some user applications. We need
to be mindful of this and work together to minimise the impact for users
while allowing RTEMS to develop better and more robust BSP interfaces.
There will need to be give on both sides.

Chris