AArch64 support and sharing of various drivers

[Christian Mauderer]

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.

> 
>>
>> shared/nxp
> 
> -1 , companies get taken over and change names.

Agreed. There are still a lot of "freescale/imx" files out there (for
example U-Boot) even if it is NXP since quite some time.

> 
>>
>> Or
>>
>> shared/IP/vendor?

Depends on how you mean that:

Is "vendor" a placeholder so that we for example get a driver

     shared/IP/arm/gicv3.c

In that case: Same problem with company names. Also it's unlikely that
ARM changes the name, it's not impossible. And we will get other vendors
in the same directory.

Or do you mean

    shared/IP/vendor/gicv3.c

In that case the directory would be a bit of a big melting pot for all
drivers without any structure.

>>
>> They need to be above a single architecture to be shared across architectures.
>>
> 
> +1
> 
>> This is just SoC IP modules that are being reused.

Sooner or later we will get more drivers. Like I said: Currently I'm in
the evaluation phase for a project where maybe a DMA is shared between
PowerPC and ARM.

Best regards

Christian

> 
> So should be use the type and then the file names can be the part?
> 
> Chris
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.