[6-freebsd-12 PATCH 1/2] rtemsbsd/bus: Add PCI support to the nexus bus

[Sebastian Huber]

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.huber at 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/