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

[Chris Johns]

On 20/10/2015 9:10 pm, Sebastian Huber wrote:
> On 20/10/15 00:46, Chris Johns wrote:
>> Was this patch posted todevel at rtems.org  for review?
> 
> No,

Should we be reviewing BSP patches?

> since this is a BSP specific patch. 

The shared BSP source tree is a grey area and I understand that. The
shared directory is treated as a convenience location for code that may
be reused at a source level.

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.

>>
>> 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.

>>   I posted an RTEMS API for FDT which seems to have been ignored.
> 
> I didn't ignore this, but I thought this is an optional add-on? The
> libfdt is a well established API. I don't see an immediate need for an
> RTEMS specific API on top of this. The FDT is used before the high level
> parts of RTEMS are available, e.g. files.

Yes the bootstrap phase is an important issue and a good design here
would be useful to other BSPs.

Yes what I posted was an optional API but it is also a useful one for
some applications. We use it to describe the PL logic in a Zynq. The
software and hardware are kept in sync via the FDT.

> 
>>
>> 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?

>>
>> Where is the documentation on how this is to be used by the BSP it is
>> designed to support? I do not see now a user is to build an application
>> to use this.
> 
> This is not for the user. This is for device driver parameters and the
> low-level system startup.

I am not familiar with the QorIQ environment. Is this documented
somewhere when building u-boot and RTEMS so it all fits together?

> 
>>
>> Which BSPs is this new BSP API intended for?
>>
>> I do not support this change and would like it reverted until a better
>> proposal is put forward.
> 
> What is your alternative? There is no way for a QorIQ device as complex
> as a T4240 without FDT.
> 

The concern is the use of the shared BSP directory. I have no grounds to
really complain because there are no real rules and this is a problem.

>>
>> On 19/10/2015 6:53 pm, Sebastian Huber wrote:
>>> >  c/src/lib/libbsp/shared/include/fdt.h             | 30 +++++++
>>> >  c/src/lib/libbsp/shared/src/bsp-fdt.c             | 59 ++++++++++++++
>> This is being adding the shared BSP API. Why?
>>
> 
> This is useful for more than one BSP.
> 

I think it is currently specific to one BSP.

Chris