[PATCH] eng: Add register block specification types

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Sep 15 05:33:05 UTC 2021


On 15/09/2021 00:48, Chris Johns wrote:
> On 14/9/21 8:08 pm, Sebastian Huber wrote:
>> On 10/09/2021 16:41, Sebastian Huber wrote:
>>> A register block may be used to specify the memory-mapped interface to
>>> the hardware.  Register blocks consist of register block members.
>>> Register block members are either instances of registers or instances of
>>> other register blocks.  Registers consists of bit fields.
>>>
>>> Update #3715.
>>
>> Any objections to integrate this?
> 
> I am sorry but in it's current form I do.
> 
>> The hardware specification is work in
>> progress. What I have currently is a proof of concept for the GR740 and the
>> GR712RC. It should cause no harm to have it documented. If this stuff is
>> generally useful is an open question.
> 
> Who fixes the spec for the other bus models?

The register block specification doesn't need to be fixed. It is 
independent of bus models, device driver frameworks, and programming 
languages. The register block specification contains the same 
information as a hardware manual in terms of register blocks, registers, 
and bit fields. The only difference is that the register block 
specification is machine readable and a hardware manual not really in 
general.

> Will those fixes be compatible and
> if not who fixes the existing specs or drivers?

In order to support a particular device driver implementation framework 
you just have to write a code generator which reads the register block 
specification and outputs the code. The existing code generator just 
outputs a header file with C structures and defines for the bit fields. 
You could use this header file with the FreeBSD bus space API.

> 
> Those questions expose the liability the project is left with. For me to make
> changes and look after the GR740 and GR712RC it would be a lot of work because I
> have not worked with those devices and they are important to some users.

The existing GRLIB header files are incomplete. What we have now is a 
complete set of register block header files for the GR740.

> 
> I do not see the value in us hosting a custom or subset solution for a model to
> access hardware we should not be encouraging.

We don't have a general bus space API in RTEMS. Basically every BSP has 
its own solution. No matter which model you have to access the hardware, 
you need something which tells you how the hardware looks like. This 
could be a manual or a machine readable description.

> I see value in a solution that can
> support all bus solutions.

I don't know if the register block specification supports all bus 
solutions, but it could support all I know currently. It is just a 
machine readable hardware description.

-- 
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/


More information about the devel mailing list