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: [email protected]
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
[email protected]
http://lists.rtems.org/mailman/listinfo/devel
