On 04/03/2021 00:18, Chris Johns wrote:
On 3/3/21 7:48 pm, Sebastian Huber wrote:
On 03/03/2021 08:52, Chris Johns wrote:
Then I hit minimum and some validation tests and they failed because I had
removed bsp/default-initial-extension.h and I suppose it needs to come via bsp.h
however it includes rtems.h because it needs to have access to
rtems_fatal_source etc.
It seems there is a lot of places that subtly depend on bsp.h and what it
includes.
I will chat to Joel tomorrow to figure out how this is to be resolved.
Any suggestions?
The minimum requirement for bsp.h is to include:
rtems.h
bspopts.h
It is news to me this is a requirement and I am unsure where it has come from.
Has it been documented? The information you cut from my last post shows RTEMS is
pretty clean and the number of issues are small so I am not sure this needs to
happen.
This is what I figured out over the years.
These powerpc BSPs predate libbsd, they have legacy networking support and are
important to RTEMS users.
Your request to not including bsp.h because it includes rtems.h in a driver
section of a third party package that needs specific BSP bus mapping information
appear to conflict. The package needs low level BSP information but it cannot
include bsp.h by definition now.
What is now bugging me is the layering of rule upon rule mixed with defaults.
The rules are complex and in places seem arbitrary. Let me write the rules out
as I understand them:
1. The BSP header bsp.h is the access to BSP interfaces
2. The BSP header bsp.h must include rtems.h and bspopt.h
3. LibBSD generic bus handling must be inline for performance reasons
4. LibBSD generic bus handling assumes cache coherent memory by default
5. BSPs must register cache coherent memory if it does not meet rule 4
6. LibBSD generic bus handling defaults to a flat 1:1 full memory space
address map
7. LibBSD generic bus handling requires bsp/bus.h to provide BSP mappings
if it does not meet rule 6
8. A BSP provided bsp/bus.h cannot include rtems.h or any header that
includes rtems.h such as bsp.h. This special case is exempt from rule 1
9. RTEMS cannot change any header an existing BSP with bsp/bus.h
includes to include rtems.h or any header that has a dependent that
includes rtems.h
<bleach> that is a lot of rules to swallow. An alternative set of rules is:
1. The BSP header bsp.h is the access to BSP interfaces
2. LibBSD generic bus handling must be inline for performance reasons
3. LibBSD generic bus handling requires a BSP provide suitable cache
coherent memory to the cache coherent memory allocator
4. LibBSD generic bus handling requires a BSP provide bsp/bus.h to
provide BSP IO mappings
The second set of rules is clear, does not self reference and universally
applies to all BSPs. It removes the defaults from LibBSD and lets us manage them
in rtems.git for a BSP. Explicitly requiring a BSP to provide support lets a
user easily check any BSP to see what cache coherent memory is configured and
what the bus handlers are.
It shall also define BSP_INITIAL_EXTENSION (normally via #include
<bsp/default-initial-extension.h>).
This is a recent addition and it is the only piece I found that has an issue
when building the motorola_powerpc. Maybe the way this is implemented is needs
to be reconsidered or we accept bsp.h does include rtems.h either directly or
indirectly.
The ability to interchange either bsp.h or rtems.h or having code that depends
on one because you include the other seems wrong.
We should move away from BSP-specific interfaces. The <bsp.h> is the
only mandatory header file provided by a BSP and may contain all sorts
of things. From my point of view the BSP should indicate which features
it requires/supports and then it should implement a standard interface.
The bus API implementation in FreeBSD is architecture-specific. We can
do this in RTEMS as well and do the implementation in cpukit, for
example based on the riscv implementation in FreeBSD. The BSP could then
simply indicate if it needs a full featured implementation or the simple
inline implementation we have currently.
The definition of BSP_INITIAL_EXTENSION can move to a separate header file.
The cache coherent memory is a different topic and I think this is
already sorted out in
http://devel.rtems.org/ticket/4243
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
