<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 08/04/2020 07:14, Sebastian Huber wrote:<br>
</p>
<blockquote type="cite"
cite="mid:95e7b5ca-9a3a-55bd-d8e9-e28cdc6b4e29@embedded-brains.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>On 08/04/2020 00:59, Chris Johns wrote:<br>
</p>
<blockquote type="cite"
cite="mid:d1cc99b8-ab84-4d76-06a1-fa0910b8029c@rtems.org">
<blockquote type="cite" style="color: #000000;">This BSP and the
libbsd build system are not good enough right now to add this
BSP to an RSB build set. <br>
</blockquote>
<br>
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. </blockquote>
<p>I think now is the wrong time to discuss this because the way
BSPs are configured will change with the new build system.</p>
<p>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? <br>
</p>
</blockquote>
<p>For the new STM32H7 BSP I used a similar approach, see attached
file.<br>
</p>
</body>
</html>