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

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Oct 21 06:07:22 UTC 2015


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

Sorry for adding stuff to the shared BSP directory without sending the 
patch for review. I also think that a review is required in general in 
this area.

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

>
>>> 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?
[...]

Yes, in the README of the BSP. U-Boot has its own documentation.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the devel mailing list