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 tode...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
