On 2020-04-07 23:36, Sebastian Huber wrote:
On 07/04/2020 15:31, Sebastian Huber wrote:
On 07/04/2020 15:26, Joel Sherrill wrote:
> ... The README says "Not all variants are tested" but I cannot see
> what has been tested? When you are new to a BSP a valid list of
what
> works is important.
The BSP runs on the evaluation board with default options.
But it doesn't build to completion? Why would someone assume a build that
fails produces a working set of exes?
I didn't claim that the libbsd build system is perfect. The libbsd
works fine if you have a board with enough RAM. The evaluation board
has only 2MiB of SDRAM. This is simply not enough for the standard tests.
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 should have tested this before I added it.
I am pleased this has happened. I prefer to know of issues and problems
ahead of time. I will be using this BSP as a test BSP for any new build
system with the RSB's vertical stack building.
This was a mistake.
I do not agree. It has exposed some limitations in what we have and what
we are doing and this is a good thing.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
