On 08/04/2020 00:59, Chris Johns wrote:
This BSP and the libbsd build system are not good enough right now to
add this BSP to an RSB build set.
I agree the build system is lacking but I do not see that as the key
issue that has been uncovered. The main issue is the addition of
"special" feature options deep in RTEMS at the BSP level, i.e.
--enable-chip. Doing this in a specific BSP may let this BSP be
functional for its users but it is outside the view of the ecosystem
and as a result the RSB does not have the machinery present to manage
that option. It might be possible I have not checked. It is really
important we all make sure BSPs and build options are managed in an
agreed consistent way so this situation is avoided.
I think now is the wrong time to discuss this because the way BSPs are
configured will change with the new build system.
The header files of this BSP support 27 chip variants: same70j19,
same70j20, same70j21, same70n19, same70n20, same70n21, same70q19,
same70q20, same70q21, sams70j19, sams70j20, sams70j21, sams70n19,
sams70n20, sams70n21, sams70q19, sams70q20, sams70q21, samv71j19,
samv71j20, samv71j21, samv71n19, samv71n20, samv71n21, samv71q19,
samv71q20, and samv71q21. What would be your alternative to a BSP option?
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
