AArch64 support and sharing of various drivers

[Sebastian Huber]

On 04/09/2020 08:38, Christian Mauderer wrote:

> On 04/09/2020 05:12, Chris Johns wrote:
>> On 4/9/20 12:43 pm, Joel Sherrill wrote:
>>> On Thu, Sep 3, 2020, 6:58 AM Christian Mauderer
>>> <christian.mauderer at embedded-brains.de
>>> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>>>
>>>      Hello Kinsey,
>>>
>>>      On 01/09/2020 23:56, Kinsey Moore wrote:
>>>      > Hi,
>>>      >
>>>      > I’ve been working on proper AArch64 support for RTEMS
>>>
>>>      That's great. It means good raspberry pi 4 support ;-)
>>>
>>>      > (versus running
>>>      > 32-bit ARM RTEMS behind a bootloader or JTAG device that switches the
>>>      > CPU to AArch32 mode) and while the vast majority of the architecture
>>>      > support code is new, lives in its own aarch64 directories, and is
>>>      > unrelated to RTEMS’s ARM support, there are several drivers living in
>>>      > the ARM shared directory that are critical to AArch64 support and many
>>>      > more that could potentially be shared. Given the limited scope of
>>>      > initial bringup on Qemu, that list is currently: GICv3, GPT(timer), and
>>>      > PL011(uart). I don’t really see a precedent for this type of sharing
>>>      > other than the global bsps/shared and bsps/include directories. The
>>>      > global shared directories might make sense for the PL011 since it could
>>>      > theoretically be used by anything that supports AXI/AMBA, but the GIC
>>>      > and GPT drivers rely on ARM system registers to function with both
>>>      > AArch32 and AArch64.
>>>      >
>>>      >
>>>      >
>>>      > In short, where should the GICv3 and GPT drivers be relocated along with
>>>      > their associated headers, if at all?
>>>      >
>>>
>>>      I might get a similar problem with some drivers shared between some
>>>      PowerPC and ARM too (NXP reuses some of the Freescale PowerPC
>>>      peripherals in up to date ARM controllers). I think in theory we already
>>>      have such drivers that maybe should be shared but are copied or
>>>      re-implemented in multiple BSPs instead.
>>>
>>> The Gaisler IP drivers were moved up in the tree recently also.
>>>
>>>      One possibility might would be to add all arm/shared to the aarch64 too.
>>>      But that is a bit unclear
>>>
>>>
>>> shared/arm??
>> shared/dev/int
>> shared/dev/serial
>>
>> ?
> shared/dev/<categories> already exist. So maybe wouldn't be a bad choice.

Drivers should be organized by device category. This helps to identify 
common code and may reduce copy and paste.

The name "irq" and not "int" is used for interrupt controller related 
code currently.