diff mbox series

[2/9] ARM: dts: socfpga: add Enclustra Intel AA1

Message ID 20240912060649.190-3-l.rubusch@gmail.com
State Changes Requested
Delegated to: Tom Rini
Headers show
Series add support for Enclustra Mercury AA1 SoMs | expand

Commit Message

Lothar Rubusch Sept. 12, 2024, 6:06 a.m. UTC
Introduce device-tree files for Enclustra Intel AA1 SoMs and related
support.

- Mercury AA1

The setup depends on a selected boot mode. Various fragments for SD/MMC
and QSPI flash boot are provided.

In combination, the following Enclustra carrier boards are supported:

- ST1
- PE1
- PE3

Signed-off-by: Andreas Buerkler <andreas.buerkler@enclustra.com>
Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
---
 arch/arm/dts/ME-AA1-270-2I2-D11E-NFX3.dtsi    |  14 +
 arch/arm/dts/ME-AA1-270-3E4-D11E-NFX3.dtsi    |  14 +
 arch/arm/dts/ME-AA1-480-2I3-D12E-NFX3.dtsi    |  15 +
 arch/arm/dts/Makefile                         |   2 +
 arch/arm/dts/enclustra-aa1.dts                |  32 ++
 .../dts/socfpga_arria10_mercury_aa1_handoff.h | 307 ++++++++++++++++++
 .../dts/socfpga_enclustra_mercury_aa1.dtsi    | 179 ++++++++++
 ...cfpga_enclustra_mercury_aa1_qspi_boot.dtsi |  18 +
 ...fpga_enclustra_mercury_aa1_sdmmc_boot.dtsi |  18 +
 .../dts/socfpga_enclustra_mercury_pe1.dtsi    |   7 +
 .../dts/socfpga_enclustra_mercury_pe3.dtsi    |   8 +
 .../dts/socfpga_enclustra_mercury_st1.dtsi    |   8 +
 12 files changed, 622 insertions(+)
 create mode 100644 arch/arm/dts/ME-AA1-270-2I2-D11E-NFX3.dtsi
 create mode 100644 arch/arm/dts/ME-AA1-270-3E4-D11E-NFX3.dtsi
 create mode 100644 arch/arm/dts/ME-AA1-480-2I3-D12E-NFX3.dtsi
 create mode 100644 arch/arm/dts/enclustra-aa1.dts
 create mode 100644 arch/arm/dts/socfpga_arria10_mercury_aa1_handoff.h
 create mode 100644 arch/arm/dts/socfpga_enclustra_mercury_aa1.dtsi
 create mode 100644 arch/arm/dts/socfpga_enclustra_mercury_aa1_qspi_boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_enclustra_mercury_aa1_sdmmc_boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_enclustra_mercury_pe1.dtsi
 create mode 100644 arch/arm/dts/socfpga_enclustra_mercury_pe3.dtsi
 create mode 100644 arch/arm/dts/socfpga_enclustra_mercury_st1.dtsi

Comments

Marek Vasut Sept. 12, 2024, 11:02 p.m. UTC | #1
On 9/12/24 8:06 AM, Lothar Rubusch wrote:
> Introduce device-tree files for Enclustra Intel AA1 SoMs and related
> support.
> 
> - Mercury AA1
> 
> The setup depends on a selected boot mode. Various fragments for SD/MMC
> and QSPI flash boot are provided.
> 
> In combination, the following Enclustra carrier boards are supported:
> 
> - ST1
> - PE1
> - PE3
> 
> Signed-off-by: Andreas Buerkler <andreas.buerkler@enclustra.com>
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
>   arch/arm/dts/ME-AA1-270-2I2-D11E-NFX3.dtsi    |  14 +
>   arch/arm/dts/ME-AA1-270-3E4-D11E-NFX3.dtsi    |  14 +
>   arch/arm/dts/ME-AA1-480-2I3-D12E-NFX3.dtsi    |  15 +
>   arch/arm/dts/Makefile                         |   2 +
>   arch/arm/dts/enclustra-aa1.dts                |  32 ++
>   .../dts/socfpga_arria10_mercury_aa1_handoff.h | 307 ++++++++++++++++++
>   .../dts/socfpga_enclustra_mercury_aa1.dtsi    | 179 ++++++++++
>   ...cfpga_enclustra_mercury_aa1_qspi_boot.dtsi |  18 +
>   ...fpga_enclustra_mercury_aa1_sdmmc_boot.dtsi |  18 +
>   .../dts/socfpga_enclustra_mercury_pe1.dtsi    |   7 +
>   .../dts/socfpga_enclustra_mercury_pe3.dtsi    |   8 +
>   .../dts/socfpga_enclustra_mercury_st1.dtsi    |   8 +
Is there any chance to upstream these DTs to Linux first , and then let 
them all trickle into U-Boot through dts/upstream/ ?
Lothar Rubusch Sept. 14, 2024, 8:14 p.m. UTC | #2
On Fri, Sep 13, 2024 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
>
> On 9/12/24 8:06 AM, Lothar Rubusch wrote:
> > Introduce device-tree files for Enclustra Intel AA1 SoMs and related
> > support.
> >
> > - Mercury AA1
> >
> > The setup depends on a selected boot mode. Various fragments for SD/MMC
> > and QSPI flash boot are provided.
> >
> > In combination, the following Enclustra carrier boards are supported:
> >
> > - ST1
> > - PE1
> > - PE3
> >
> > Signed-off-by: Andreas Buerkler <andreas.buerkler@enclustra.com>
> > Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> > ---
> >   arch/arm/dts/ME-AA1-270-2I2-D11E-NFX3.dtsi    |  14 +
> >   arch/arm/dts/ME-AA1-270-3E4-D11E-NFX3.dtsi    |  14 +
> >   arch/arm/dts/ME-AA1-480-2I3-D12E-NFX3.dtsi    |  15 +
> >   arch/arm/dts/Makefile                         |   2 +
> >   arch/arm/dts/enclustra-aa1.dts                |  32 ++
> >   .../dts/socfpga_arria10_mercury_aa1_handoff.h | 307 ++++++++++++++++++
> >   .../dts/socfpga_enclustra_mercury_aa1.dtsi    | 179 ++++++++++
> >   ...cfpga_enclustra_mercury_aa1_qspi_boot.dtsi |  18 +
> >   ...fpga_enclustra_mercury_aa1_sdmmc_boot.dtsi |  18 +
> >   .../dts/socfpga_enclustra_mercury_pe1.dtsi    |   7 +
> >   .../dts/socfpga_enclustra_mercury_pe3.dtsi    |   8 +
> >   .../dts/socfpga_enclustra_mercury_st1.dtsi    |   8 +
> Is there any chance to upstream these DTs to Linux first , and then let
> them all trickle into U-Boot through dts/upstream/ ?

This is the tricky one. In principle, as it is supposed to be build on
our side this is not the case. For the kernel, we prefer to work with
DT overlays (.dtbo) where on the u-boot side we only need some basic
functionality and not everything declared. So, currently there are
differences.

Another point here for me to understand would be the following. If I
upstream some DT files to  the kernel it might take time until they go
to anything released there. So, upstreaming u-boot would wait on that
kernel release, right? In such case, I really prefer to upstream the
DT files as is to u-boot first. Then / In parallel try  to upstream
the files to the kernel. And update the u-boot DT set to point to the
kernel DT files when they are released. Could this be an approach?

Anyway, it might be that next week, I might discuss that directly in
person to get a better idea what could be a way for me with those
u-boot files. I'm coming back to this topic then. If you find some
time, please let me know what you think about it.
Lothar Rubusch Sept. 25, 2024, 10:49 p.m. UTC | #3
First of all a huge thank you for the time you spend in reviewing the
patches so far. This is highly appreciate!!


On Fri, Sep 13, 2024 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
[...]
> Is there any chance to upstream these DTs to Linux first , and then let
> them all trickle into U-Boot through dts/upstream/ ?

Preparing the DTS patches for Linux kernel, I noticed I will need the
handoff setup for u-boot. AFAIK there is currently no single handoff.h
or handoff.dtsi file in the kernel repo.

Shall I add the files to my DTS patches and ask for upstreaming of the
handoff files into the kernel?

Example:
In specific for u-boot I need a .dts setup like this. Those files are
currently not in the kernel:
    #include "socfpga_arria10_mercury_aa1_handoff.h"
    #include "socfpga_arria10-handoff.dtsi"
    #include "socfpga_arria10_handoff_u-boot.dtsi"
    ...

Since this seems to be common for all socfpga setups (arria10 and
cyclone5), I guess the situation is already known by a common
approach. How to deal with this situation in u-boot dts/upstream?
Marek Vasut Sept. 26, 2024, 1:33 a.m. UTC | #4
On 9/26/24 12:49 AM, Lothar Rubusch wrote:

Hi,

> First of all a huge thank you for the time you spend in reviewing the
> patches so far. This is highly appreciate!!
> 
> 
> On Fri, Sep 13, 2024 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
> [...]
>> Is there any chance to upstream these DTs to Linux first , and then let
>> them all trickle into U-Boot through dts/upstream/ ?
> 
> Preparing the DTS patches for Linux kernel, I noticed I will need the
> handoff setup for u-boot. AFAIK there is currently no single handoff.h
> or handoff.dtsi file in the kernel repo.
> 
> Shall I add the files to my DTS patches and ask for upstreaming of the
> handoff files into the kernel?

Are the handoff files really used by Linux for anything , or do they 
contain various clock/pinmux/DRAM settings only used by U-Boot ? If the 
later, place them into U-Boot and include them from -u-boot.dtsi file.

> Example:
> In specific for u-boot I need a .dts setup like this. Those files are
> currently not in the kernel:
>      #include "socfpga_arria10_mercury_aa1_handoff.h"
>      #include "socfpga_arria10-handoff.dtsi"
>      #include "socfpga_arria10_handoff_u-boot.dtsi"
>      ...
> 
> Since this seems to be common for all socfpga setups (arria10 and
> cyclone5), I guess the situation is already known by a common
> approach. How to deal with this situation in u-boot dts/upstream?
Lothar Rubusch Sept. 26, 2024, 10:53 p.m. UTC | #5
On Thu, Sep 26, 2024 at 3:36 AM Marek Vasut <marex@denx.de> wrote:
>
> On 9/26/24 12:49 AM, Lothar Rubusch wrote:
>
> Hi,
[...]
> > Shall I add the files to my DTS patches and ask for upstreaming of the
> > handoff files into the kernel?
>
> Are the handoff files really used by Linux for anything , or do they
> contain various clock/pinmux/DRAM settings only used by U-Boot ? If the
> later, place them into U-Boot and include them from -u-boot.dtsi file.

Similar to the other socfpga targets, the handoff files are just
relevant to u-boot. So, I'll keep them in arch/arm/dts.

My particular situation then is as follows. The .dts file just
includes several .dtsi files. I place this .dts file into
arch/arm/dts. The first includes contain the "handoff setup". Then I
include adjustments (.dtsi fragments) to the selected base-board and
boot-mode. Both  can vary that's why I really would prefer to allow
for a Kconfig option on that, in contrary to provide a set of .dts
files for all possible combinations.

Example:
$ cat ./arch/arm/dts/socfpga_arria10_mercury_aa1_pe1_sdmmc-u-boot.dts
/dts-v1/;
/* will be taken from /arch/arm/dts */
#include "socfpga_arria10_mercury_aa1_handoff.h"
#include "socfpga_arria10-handoff.dtsi"
#include "socfpga_arria10_handoff_u-boot.dtsi"

/* will be taken from /dts/upstream */
#include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_arria10_mercury_aa1.dtsi"
#include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_enclustra_mercury_bootmode_sdmmc.dtsi"
#include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_enclustra_mercury_pe1.dtsi"

Ideally, now I like to have the first part as default device tree.
DEFAULT_DEVICE_TREE=socfpga_arria10_mercury_aa1_pe1_sdmmc-u-boot.dts
When doing so, I noticed I cannot enable CONFIG_OF_UPSTREAM anymore,
the files in arch/arm/dts won't be found anymore.
Then I have the issue how to access the generic .dtsi files used for
boot-mode or base board. These files are identical to the kernel DT
why I would prefer to use them from dts/upstream. Including them like
../../../../../... works, but... I think there must be a better way.
Ideally I like to setup some Kconfig choice for base board selection
and one for boot-mode.

1.) In the documentation control.rst I read that the u-boot.dts is
combined of several elements. Is there a way to take this base .dts,
then add a base board .dtsi by Kconfig option, and similar a
boot-mode?

2.) Is there a way to enable CONFIG_OF_UPSTREAM and use explicit DTS
from arch/arm/dts for the u-boot?

3.) What would be the best possibility to have a u-boot.dts with
handoff setup in arch/arm/dts and append .dtsi files from the general
dts/upstream - in case are there other boards are doing something
similar?
Marek Vasut Sept. 26, 2024, 11:13 p.m. UTC | #6
On 9/27/24 12:53 AM, Lothar Rubusch wrote:
> On Thu, Sep 26, 2024 at 3:36 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 9/26/24 12:49 AM, Lothar Rubusch wrote:
>>
>> Hi,
> [...]
>>> Shall I add the files to my DTS patches and ask for upstreaming of the
>>> handoff files into the kernel?
>>
>> Are the handoff files really used by Linux for anything , or do they
>> contain various clock/pinmux/DRAM settings only used by U-Boot ? If the
>> later, place them into U-Boot and include them from -u-boot.dtsi file.
> 
> Similar to the other socfpga targets, the handoff files are just
> relevant to u-boot. So, I'll keep them in arch/arm/dts.

Right

> My particular situation then is as follows. The .dts file just
> includes several .dtsi files. I place this .dts file into
> arch/arm/dts. The first includes contain the "handoff setup". Then I
> include adjustments (.dtsi fragments) to the selected base-board and
> boot-mode. Both  can vary that's why I really would prefer to allow
> for a Kconfig option on that, in contrary to provide a set of .dts
> files for all possible combinations.
> 
> Example:
> $ cat ./arch/arm/dts/socfpga_arria10_mercury_aa1_pe1_sdmmc-u-boot.dts

Upstream DT named this way into Linux:

socfpga_arria10_mercury_aa1_pe1_sdmmc.dts

And then in U-Boot, implement the extras which include whatever you 
need, name the file:

socfpga_arria10_mercury_aa1_pe1_sdmmc-u-boot.dtsi

The U-Boot build system will combine the two DTs, the build system 
should automatically append matching -u-boot.dtsi content to any .dts file.

I am not sure if this also works if the .dts file is in dts/upstream/* 
while the -u-boot.dtsi is in arch/*/dts/ , but there is now definitely a 
use case for such a setup, it is probably a matter of tweaking the 
Makefiles .

> /dts-v1/;
> /* will be taken from /arch/arm/dts */
> #include "socfpga_arria10_mercury_aa1_handoff.h"
> #include "socfpga_arria10-handoff.dtsi"
> #include "socfpga_arria10_handoff_u-boot.dtsi"
> 
> /* will be taken from /dts/upstream */
> #include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_arria10_mercury_aa1.dtsi"
> #include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_enclustra_mercury_bootmode_sdmmc.dtsi"
> #include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_enclustra_mercury_pe1.dtsi"
> 
> Ideally, now I like to have the first part as default device tree.
> DEFAULT_DEVICE_TREE=socfpga_arria10_mercury_aa1_pe1_sdmmc-u-boot.dts
> When doing so, I noticed I cannot enable CONFIG_OF_UPSTREAM anymore,
> the files in arch/arm/dts won't be found anymore.
> Then I have the issue how to access the generic .dtsi files used for
> boot-mode or base board. These files are identical to the kernel DT
> why I would prefer to use them from dts/upstream. Including them like
> ../../../../../... works, but... I think there must be a better way.

Look at how the -u-boot.dtsi are automatically added on top of .dts 
files, that might be a start.

> Ideally I like to setup some Kconfig choice for base board selection
> and one for boot-mode.

> 1.) In the documentation control.rst I read that the u-boot.dts is
> combined of several elements. Is there a way to take this base .dts,
> then add a base board .dtsi by Kconfig option, and similar a
> boot-mode?

The -u-boot.dtsi is preprocessed by C preprocessor, just like all the 
other DTs, so you can have a -u-boot.dtsi file which contains C 
preprocessor conditional statements in it to conditionally include other 
.dtsi files:

#if IS_ENABLED(...)
#include ...
#else ...
...
#endif

> 2.) Is there a way to enable CONFIG_OF_UPSTREAM and use explicit DTS
> from arch/arm/dts for the u-boot?

This I do not know.

> 3.) What would be the best possibility to have a u-boot.dts with
> handoff setup in arch/arm/dts and append .dtsi files from the general
> dts/upstream - in case are there other boards are doing something
> similar?

See above, maybe some of it helps.
Lothar Rubusch Sept. 27, 2024, 10:47 p.m. UTC | #7
On Fri, Sep 27, 2024 at 1:19 AM Marek Vasut <marex@denx.de> wrote:
>
> On 9/27/24 12:53 AM, Lothar Rubusch wrote:
> > On Thu, Sep 26, 2024 at 3:36 AM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 9/26/24 12:49 AM, Lothar Rubusch wrote:
> >>
> >> Hi,
> > [...]
> >>> Shall I add the files to my DTS patches and ask for upstreaming of the
> >>> handoff files into the kernel?
> >>
> >> Are the handoff files really used by Linux for anything , or do they
> >> contain various clock/pinmux/DRAM settings only used by U-Boot ? If the
> >> later, place them into U-Boot and include them from -u-boot.dtsi file.
> >
> > Similar to the other socfpga targets, the handoff files are just
> > relevant to u-boot. So, I'll keep them in arch/arm/dts.
>
> Right
>
> > My particular situation then is as follows. The .dts file just
> > includes several .dtsi files. I place this .dts file into
> > arch/arm/dts. The first includes contain the "handoff setup". Then I
> > include adjustments (.dtsi fragments) to the selected base-board and
> > boot-mode. Both  can vary that's why I really would prefer to allow
> > for a Kconfig option on that, in contrary to provide a set of .dts
> > files for all possible combinations.
> >
> > Example:
> > $ cat ./arch/arm/dts/socfpga_arria10_mercury_aa1_pe1_sdmmc-u-boot.dts
>
> Upstream DT named this way into Linux:
>
> socfpga_arria10_mercury_aa1_pe1_sdmmc.dts
>
> And then in U-Boot, implement the extras which include whatever you
> need, name the file:
>
> socfpga_arria10_mercury_aa1_pe1_sdmmc-u-boot.dtsi
>
> The U-Boot build system will combine the two DTs, the build system
> should automatically append matching -u-boot.dtsi content to any .dts file.
>
> I am not sure if this also works if the .dts file is in dts/upstream/*
> while the -u-boot.dtsi is in arch/*/dts/ , but there is now definitely a
> use case for such a setup, it is probably a matter of tweaking the
> Makefiles .
>
> > /dts-v1/;
> > /* will be taken from /arch/arm/dts */
> > #include "socfpga_arria10_mercury_aa1_handoff.h"
> > #include "socfpga_arria10-handoff.dtsi"
> > #include "socfpga_arria10_handoff_u-boot.dtsi"
> >
> > /* will be taken from /dts/upstream */
> > #include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_arria10_mercury_aa1.dtsi"
> > #include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_enclustra_mercury_bootmode_sdmmc.dtsi"
> > #include "../../../dts/upstream/src/arm/intel/socfpga/socfpga_enclustra_mercury_pe1.dtsi"
> >
> > Ideally, now I like to have the first part as default device tree.
> > DEFAULT_DEVICE_TREE=socfpga_arria10_mercury_aa1_pe1_sdmmc-u-boot.dts
> > When doing so, I noticed I cannot enable CONFIG_OF_UPSTREAM anymore,
> > the files in arch/arm/dts won't be found anymore.
> > Then I have the issue how to access the generic .dtsi files used for
> > boot-mode or base board. These files are identical to the kernel DT
> > why I would prefer to use them from dts/upstream. Including them like
> > ../../../../../... works, but... I think there must be a better way.
>
> Look at how the -u-boot.dtsi are automatically added on top of .dts
> files, that might be a start.
>
> > Ideally I like to setup some Kconfig choice for base board selection
> > and one for boot-mode.
>
> > 1.) In the documentation control.rst I read that the u-boot.dts is
> > combined of several elements. Is there a way to take this base .dts,
> > then add a base board .dtsi by Kconfig option, and similar a
> > boot-mode?
>
> The -u-boot.dtsi is preprocessed by C preprocessor, just like all the
> other DTs, so you can have a -u-boot.dtsi file which contains C
> preprocessor conditional statements in it to conditionally include other
> .dtsi files:
>
> #if IS_ENABLED(...)
> #include ...
> #else ...
> ...
> #endif

Going through the include list setup by the Makefile made me find my
mistake. Currently I may use u-boot specific stuff in arch/arm/dts and
include generic .dtsi fragments from dts/upstream. Note: I'm not
setting CONFIG_OF_UPSTREAM since I'm using the regular include list
which already contains dts/upstream/src/arm/intel. Is this ok? Or,
shall I try a different approach, which involves having
CONFIG_OF_UPSTREAM explicitely set in the defconfig?

> > 3.) What would be the best possibility to have a u-boot.dts with
> > handoff setup in arch/arm/dts and append .dtsi files from the general
> > dts/upstream - in case are there other boards are doing something
> > similar?
>
> See above, maybe some of it helps.

Yes. This helped. I can set base-board and boot mode now by Kconfig
option with a generic .dts file. Note, it may still take some time,
since I'd like to test the stuff still a bit on hardware before
submitting something to the list.
Marek Vasut Sept. 29, 2024, 3:20 p.m. UTC | #8
On 9/28/24 12:47 AM, Lothar Rubusch wrote:

[...]

>>> Ideally I like to setup some Kconfig choice for base board selection
>>> and one for boot-mode.
>>
>>> 1.) In the documentation control.rst I read that the u-boot.dts is
>>> combined of several elements. Is there a way to take this base .dts,
>>> then add a base board .dtsi by Kconfig option, and similar a
>>> boot-mode?
>>
>> The -u-boot.dtsi is preprocessed by C preprocessor, just like all the
>> other DTs, so you can have a -u-boot.dtsi file which contains C
>> preprocessor conditional statements in it to conditionally include other
>> .dtsi files:
>>
>> #if IS_ENABLED(...)
>> #include ...
>> #else ...
>> ...
>> #endif
> 
> Going through the include list setup by the Makefile made me find my
> mistake. Currently I may use u-boot specific stuff in arch/arm/dts and
> include generic .dtsi fragments from dts/upstream. Note: I'm not
> setting CONFIG_OF_UPSTREAM since I'm using the regular include list
> which already contains dts/upstream/src/arm/intel. Is this ok? Or,
> shall I try a different approach, which involves having
> CONFIG_OF_UPSTREAM explicitely set in the defconfig?

I'm not quite sure I understand the question. Once this platform DTs 
land in mainline and the DTs get synchronized into U-Boot, you should 
then set CONFIG_OF_UPSTREAM. Until then, you could patch the DTs into 
dts/upstream/ to test the result with OF_UPSTREAM enabled .

>>> 3.) What would be the best possibility to have a u-boot.dts with
>>> handoff setup in arch/arm/dts and append .dtsi files from the general
>>> dts/upstream - in case are there other boards are doing something
>>> similar?
>>
>> See above, maybe some of it helps.
> 
> Yes. This helped. I can set base-board and boot mode now by Kconfig
> option with a generic .dts file. Note, it may still take some time,
> since I'd like to test the stuff still a bit on hardware before
> submitting something to the list.

Sure
Lothar Rubusch Sept. 29, 2024, 7:19 p.m. UTC | #9
On Sun, Sep 29, 2024 at 6:55 PM Marek Vasut <marex@denx.de> wrote:
>
> On 9/28/24 12:47 AM, Lothar Rubusch wrote:
>
> [...]
>
> >>> Ideally I like to setup some Kconfig choice for base board selection
> >>> and one for boot-mode.
> >>
> >>> 1.) In the documentation control.rst I read that the u-boot.dts is
> >>> combined of several elements. Is there a way to take this base .dts,
> >>> then add a base board .dtsi by Kconfig option, and similar a
> >>> boot-mode?
> >>
> >> The -u-boot.dtsi is preprocessed by C preprocessor, just like all the
> >> other DTs, so you can have a -u-boot.dtsi file which contains C
> >> preprocessor conditional statements in it to conditionally include other
> >> .dtsi files:
> >>
> >> #if IS_ENABLED(...)
> >> #include ...
> >> #else ...
> >> ...
> >> #endif
> >
> > Going through the include list setup by the Makefile made me find my
> > mistake. Currently I may use u-boot specific stuff in arch/arm/dts and
> > include generic .dtsi fragments from dts/upstream. Note: I'm not
> > setting CONFIG_OF_UPSTREAM since I'm using the regular include list
> > which already contains dts/upstream/src/arm/intel. Is this ok? Or,
> > shall I try a different approach, which involves having
> > CONFIG_OF_UPSTREAM explicitely set in the defconfig?
>
> I'm not quite sure I understand the question. Once this platform DTs
> land in mainline and the DTs get synchronized into U-Boot, you should
> then set CONFIG_OF_UPSTREAM. Until then, you could patch the DTs into
> dts/upstream/ to test the result with OF_UPSTREAM enabled .
>

Ah, sorry. I did not explain well. Currently I patch the DTs which
should go to kernel/mainline into my local u-boot:
dts/upstream/src/arm/intel/socfpga/ as a preparation for my test
builds.

For U-boot I will need to build a devicetree file from archarm/dts. I
cannot rely just on the upstream fragments for u-boot. Imagine
settings like initial fpga bitstream loading, handoff file setup for
initialization, etc. In parts I may use .dtsi files from dts/upstream,
though, but most of the u-boot particular devicetree setup will reside
in arch/arm/dts, I guess (you may see later in the patches).

I noticed when setting the option CONFIG_OF_UPSTREAM in `make
menuconfig`, it prepends `dts/upstream/` to the included paths of the
devicetree files. The resulting path for the .dts was then
dts/upstream/arch/arm/dts/ and could not be found anymore. When I
don't activate CONFIG_OF_UPSTREAM, dts/upstream is in the Makefile's
include list anyway so that I easily can include from both locations.

In conclusion, currently I'm calling a .dts for building the u-boot DT
from arch/arm/dts. The file includes upstream stuff as .dtsi fragment
from dts/upstream and handoff from local. CONFIG_OF_UPSTREAM does not
seem to be necessary in this case.

This approach currently works for me. If you strongly disagree, I may
invest more time to find a way (or why there is currently no way) with
CONFIG_OF_UPSTREAM.

This was my question about. Anyway you may wait on v3 to understand
better in source what I'm doing, or if I'm just messing around.

> >>> 3.) What would be the best possibility to have a u-boot.dts with
> >>> handoff setup in arch/arm/dts and append .dtsi files from the general
> >>> dts/upstream - in case are there other boards are doing something
> >>> similar?
> >>
> >> See above, maybe some of it helps.
> >
> > Yes. This helped. I can set base-board and boot mode now by Kconfig
> > option with a generic .dts file. Note, it may still take some time,
> > since I'd like to test the stuff still a bit on hardware before
> > submitting something to the list.
>
> Sure

I still found some bugs. When it's working (again), I'll let you guys know..
Marek Vasut Oct. 5, 2024, 1:23 a.m. UTC | #10
On 9/29/24 9:19 PM, Lothar Rubusch wrote:
> On Sun, Sep 29, 2024 at 6:55 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 9/28/24 12:47 AM, Lothar Rubusch wrote:
>>
>> [...]
>>
>>>>> Ideally I like to setup some Kconfig choice for base board selection
>>>>> and one for boot-mode.
>>>>
>>>>> 1.) In the documentation control.rst I read that the u-boot.dts is
>>>>> combined of several elements. Is there a way to take this base .dts,
>>>>> then add a base board .dtsi by Kconfig option, and similar a
>>>>> boot-mode?
>>>>
>>>> The -u-boot.dtsi is preprocessed by C preprocessor, just like all the
>>>> other DTs, so you can have a -u-boot.dtsi file which contains C
>>>> preprocessor conditional statements in it to conditionally include other
>>>> .dtsi files:
>>>>
>>>> #if IS_ENABLED(...)
>>>> #include ...
>>>> #else ...
>>>> ...
>>>> #endif
>>>
>>> Going through the include list setup by the Makefile made me find my
>>> mistake. Currently I may use u-boot specific stuff in arch/arm/dts and
>>> include generic .dtsi fragments from dts/upstream. Note: I'm not
>>> setting CONFIG_OF_UPSTREAM since I'm using the regular include list
>>> which already contains dts/upstream/src/arm/intel. Is this ok? Or,
>>> shall I try a different approach, which involves having
>>> CONFIG_OF_UPSTREAM explicitely set in the defconfig?
>>
>> I'm not quite sure I understand the question. Once this platform DTs
>> land in mainline and the DTs get synchronized into U-Boot, you should
>> then set CONFIG_OF_UPSTREAM. Until then, you could patch the DTs into
>> dts/upstream/ to test the result with OF_UPSTREAM enabled .
>>
> 
> Ah, sorry. I did not explain well. Currently I patch the DTs which
> should go to kernel/mainline into my local u-boot:
> dts/upstream/src/arm/intel/socfpga/ as a preparation for my test
> builds.

OK

> For U-boot I will need to build a devicetree file from archarm/dts. I
> cannot rely just on the upstream fragments for u-boot. Imagine
> settings like initial fpga bitstream loading, handoff file setup for
> initialization, etc. In parts I may use .dtsi files from dts/upstream,
> though, but most of the u-boot particular devicetree setup will reside
> in arch/arm/dts, I guess (you may see later in the patches).

You should be able to use dts/upstream/src/arm/intel/socfpga/ with 
-u-boot.dtsi from arch/arm/dts/ for this purpose, right ?

> I noticed when setting the option CONFIG_OF_UPSTREAM in `make
> menuconfig`, it prepends `dts/upstream/` to the included paths of the
> devicetree files. The resulting path for the .dts was then
> dts/upstream/arch/arm/dts/ and could not be found anymore. When I
> don't activate CONFIG_OF_UPSTREAM, dts/upstream is in the Makefile's
> include list anyway so that I easily can include from both locations.

+CC Sumit

> In conclusion, currently I'm calling a .dts for building the u-boot DT
> from arch/arm/dts. The file includes upstream stuff as .dtsi fragment
> from dts/upstream and handoff from local. CONFIG_OF_UPSTREAM does not
> seem to be necessary in this case.
> 
> This approach currently works for me. If you strongly disagree, I may
> invest more time to find a way (or why there is currently no way) with
> CONFIG_OF_UPSTREAM.
> 
> This was my question about. Anyway you may wait on v3 to understand
> better in source what I'm doing, or if I'm just messing around.
I'll wait for V3, sure, good luck.

Sorry for the delayed reply.
Sumit Garg Oct. 7, 2024, 10:20 a.m. UTC | #11
On Sat, 5 Oct 2024 at 07:14, Marek Vasut <marex@denx.de> wrote:
>
> On 9/29/24 9:19 PM, Lothar Rubusch wrote:
> > On Sun, Sep 29, 2024 at 6:55 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 9/28/24 12:47 AM, Lothar Rubusch wrote:
> >>
> >> [...]
> >>
> >>>>> Ideally I like to setup some Kconfig choice for base board selection
> >>>>> and one for boot-mode.
> >>>>
> >>>>> 1.) In the documentation control.rst I read that the u-boot.dts is
> >>>>> combined of several elements. Is there a way to take this base .dts,
> >>>>> then add a base board .dtsi by Kconfig option, and similar a
> >>>>> boot-mode?
> >>>>
> >>>> The -u-boot.dtsi is preprocessed by C preprocessor, just like all the
> >>>> other DTs, so you can have a -u-boot.dtsi file which contains C
> >>>> preprocessor conditional statements in it to conditionally include other
> >>>> .dtsi files:
> >>>>
> >>>> #if IS_ENABLED(...)
> >>>> #include ...
> >>>> #else ...
> >>>> ...
> >>>> #endif
> >>>
> >>> Going through the include list setup by the Makefile made me find my
> >>> mistake. Currently I may use u-boot specific stuff in arch/arm/dts and
> >>> include generic .dtsi fragments from dts/upstream. Note: I'm not
> >>> setting CONFIG_OF_UPSTREAM since I'm using the regular include list
> >>> which already contains dts/upstream/src/arm/intel. Is this ok? Or,
> >>> shall I try a different approach, which involves having
> >>> CONFIG_OF_UPSTREAM explicitely set in the defconfig?
> >>
> >> I'm not quite sure I understand the question. Once this platform DTs
> >> land in mainline and the DTs get synchronized into U-Boot, you should
> >> then set CONFIG_OF_UPSTREAM. Until then, you could patch the DTs into
> >> dts/upstream/ to test the result with OF_UPSTREAM enabled .
> >>
> >
> > Ah, sorry. I did not explain well. Currently I patch the DTs which
> > should go to kernel/mainline into my local u-boot:
> > dts/upstream/src/arm/intel/socfpga/ as a preparation for my test
> > builds.
>
> OK
>
> > For U-boot I will need to build a devicetree file from archarm/dts. I
> > cannot rely just on the upstream fragments for u-boot. Imagine
> > settings like initial fpga bitstream loading, handoff file setup for
> > initialization, etc. In parts I may use .dtsi files from dts/upstream,
> > though, but most of the u-boot particular devicetree setup will reside
> > in arch/arm/dts, I guess (you may see later in the patches).
>
> You should be able to use dts/upstream/src/arm/intel/socfpga/ with
> -u-boot.dtsi from arch/arm/dts/ for this purpose, right ?

Yeah that's a possibility. But are there any plans on pushing
currently U-Boot specific DT bits to upstream DT (Linux kernel
source)?

>
> > I noticed when setting the option CONFIG_OF_UPSTREAM in `make
> > menuconfig`, it prepends `dts/upstream/` to the included paths of the
> > devicetree files. The resulting path for the .dts was then
> > dts/upstream/arch/arm/dts/ and could not be found anymore. When I
> > don't activate CONFIG_OF_UPSTREAM, dts/upstream is in the Makefile's
> > include list anyway so that I easily can include from both locations.
>
> +CC Sumit
>

Yeah that's true it's done on purpose to allow reuse of DT sources
includes (.dtsi or header files) even when CONFIG_OF_UPSTREAM isn't
enabled.

-Sumit

> > In conclusion, currently I'm calling a .dts for building the u-boot DT
> > from arch/arm/dts. The file includes upstream stuff as .dtsi fragment
> > from dts/upstream and handoff from local. CONFIG_OF_UPSTREAM does not
> > seem to be necessary in this case.
> >
> > This approach currently works for me. If you strongly disagree, I may
> > invest more time to find a way (or why there is currently no way) with
> > CONFIG_OF_UPSTREAM.
> >
> > This was my question about. Anyway you may wait on v3 to understand
> > better in source what I'm doing, or if I'm just messing around.
> I'll wait for V3, sure, good luck.
>
> Sorry for the delayed reply.
Lothar Rubusch Oct. 7, 2024, 1:59 p.m. UTC | #12
Dear U-boot community!

On Mon, Oct 7, 2024 at 12:21 PM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Sat, 5 Oct 2024 at 07:14, Marek Vasut <marex@denx.de> wrote:
> >
> > On 9/29/24 9:19 PM, Lothar Rubusch wrote:
> > > On Sun, Sep 29, 2024 at 6:55 PM Marek Vasut <marex@denx.de> wrote:
> > >>
> > >> On 9/28/24 12:47 AM, Lothar Rubusch wrote:
> > >>
> > >>>> [...]
> > > For U-boot I will need to build a devicetree file from archarm/dts. I
> > > cannot rely just on the upstream fragments for u-boot. Imagine
> > > settings like initial fpga bitstream loading, handoff file setup for
> > > initialization, etc. In parts I may use .dtsi files from dts/upstream,
> > > though, but most of the u-boot particular devicetree setup will reside
> > > in arch/arm/dts, I guess (you may see later in the patches).
> >
> > You should be able to use dts/upstream/src/arm/intel/socfpga/ with
> > -u-boot.dtsi from arch/arm/dts/ for this purpose, right ?
>
> Yeah that's a possibility. But are there any plans on pushing
> currently U-Boot specific DT bits to upstream DT (Linux kernel
> source)?
>

Hum, I have certain requirements when working with Arria10 Socfpga
SoMs. Here, I need..
- to do the handoff initialization from DTS (only in u-boot)
- to setup a fpga loader for the bitstream in the DTS (only in u-boot/spl)
- to adjust the boot media, needed for u-boot to know from where to
load the fpga.itb
- and to mux the boot-mode in the DT, e.g. QSPI off when booting from
MMC, and vice versa

So, time has passed a bit. I don't need different memory declarations.
I don't need DTBOs, but I'm applying the  #if IS_ENABLED(CONFIG_..)
approach, just great! This reduces complexity by far and I can load
the major part from dts/upstream. For the rest I noticed the Google
Chameleon HW takes a somehow similar approach and I tried to align my
DTS setup to use common base for the handoff and early init approach,
which reduces the need to add additional files.

Nevertheless, I have to not enable CONFIG_OF_UPSTREAM, since I need to
keep the .dts file to reside in arch/arm/dts then taking some of the
.dtsi files from dts/upstream. This works and I'll present my solution
very soon.

> >
> > > I noticed when setting the option CONFIG_OF_UPSTREAM in `make
> > > menuconfig`, it prepends `dts/upstream/` to the included paths of the
> > > devicetree files. The resulting path for the .dts was then
> > > dts/upstream/arch/arm/dts/ and could not be found anymore. When I
> > > don't activate CONFIG_OF_UPSTREAM, dts/upstream is in the Makefile's
> > > include list anyway so that I easily can include from both locations.
> >
> > +CC Sumit
> >
>
> Yeah that's true it's done on purpose to allow reuse of DT sources
> includes (.dtsi or header files) even when CONFIG_OF_UPSTREAM isn't
> enabled.
>

As I said to me this comes in very handy.

So, as an update, I started upstreaming of my DTS parts to the kernel,
at least Marek should be in CC, here.

To the u-boot v3 patch set I prepared further brush ups. I changed
over to  using standard boot env, and currently pretend removing all
of the manually provided env. I tried to get further rid of deprecated
things and after a major rework of the DT approach now I have mainly
one blocking issue.

I'm not sure, perhaps I'll send you the patches together with the
question: The altera_set_storage  command in  the u-boot env was
working with the old GPIO API and without using the DM. So, I defined
a small U_BOOT_DRIVER(). I don't want to have DT binding for that
device, but rather coming up, when I call
uclass_get_device_by_driver(). Nevertheless, this function now does
not give me a valid device back.
IMHO I don't even need an extra bind() or probe(), anyway I tried
with/without explicit bind(), with probe(), I tried even to do a
crafted binding in the DT with the of_match table. But seems I'm
missing something essential. I saw other drivers could use GPIOs
relatively simple. Do you know an example where I could have a look
at?

Then I would use this device and simply implement the
altera_set_storage functionaly by the modern GPIO API on the device.
I'm a bit unsure what I'm doing wrong here. Perhaps I may show the
patches with this issue?

Best regards,
L
diff mbox series

Patch

diff --git a/arch/arm/dts/ME-AA1-270-2I2-D11E-NFX3.dtsi b/arch/arm/dts/ME-AA1-270-2I2-D11E-NFX3.dtsi
new file mode 100644
index 0000000000..75550a77c9
--- /dev/null
+++ b/arch/arm/dts/ME-AA1-270-2I2-D11E-NFX3.dtsi
@@ -0,0 +1,14 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+/ {
+	model = "Enclustra Mercury+ AA1";
+
+	memory@0 {
+		name = "memory";
+		device_type = "memory";
+		reg = <0x0 0x80000000>; /* 2GB */
+	};
+};
diff --git a/arch/arm/dts/ME-AA1-270-3E4-D11E-NFX3.dtsi b/arch/arm/dts/ME-AA1-270-3E4-D11E-NFX3.dtsi
new file mode 100644
index 0000000000..75550a77c9
--- /dev/null
+++ b/arch/arm/dts/ME-AA1-270-3E4-D11E-NFX3.dtsi
@@ -0,0 +1,14 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+/ {
+	model = "Enclustra Mercury+ AA1";
+
+	memory@0 {
+		name = "memory";
+		device_type = "memory";
+		reg = <0x0 0x80000000>; /* 2GB */
+	};
+};
diff --git a/arch/arm/dts/ME-AA1-480-2I3-D12E-NFX3.dtsi b/arch/arm/dts/ME-AA1-480-2I3-D12E-NFX3.dtsi
new file mode 100644
index 0000000000..9ba850a84b
--- /dev/null
+++ b/arch/arm/dts/ME-AA1-480-2I3-D12E-NFX3.dtsi
@@ -0,0 +1,15 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+/ {
+	model = "Enclustra Mercury+ AA1";
+
+	/* The module is equipped with 4Gbyte RAM but U-Boot limits the size to 2 Gbyte */
+	memory@0 {
+		name = "memory";
+		device_type = "memory";
+		reg = <0x0 0x80000000>; /* 2GB */
+	};
+};
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 64007a20e6..2fcc4512ef 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -414,6 +414,8 @@  dtb-$(CONFIG_ARCH_SOCFPGA) +=				\
 	socfpga_n5x_socdk.dtb				\
 	socfpga_stratix10_socdk.dtb
 
+dtb-$(CONFIG_TARGET_SOCFPGA_ENCLUSTRA_MERCURY_AA1) += enclustra-aa1.dtb
+
 dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb	\
 	dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb
 dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
diff --git a/arch/arm/dts/enclustra-aa1.dts b/arch/arm/dts/enclustra-aa1.dts
new file mode 100644
index 0000000000..09df8c846a
--- /dev/null
+++ b/arch/arm/dts/enclustra-aa1.dts
@@ -0,0 +1,32 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+/dts-v1/;
+
+/* arria10 family - NB: keep the order of the includes */
+#include "socfpga_arria10.dtsi"
+#include "socfpga_arria10-u-boot.dtsi"
+
+/* The generated handoff.h goes here */
+#include "socfpga_arria10_mercury_aa1_handoff.h"
+
+/* Generic arria10 glue */
+#include "socfpga_arria10-handoff.dtsi"
+#include "socfpga_arria10_handoff_u-boot.dtsi"
+#include "socfpga_enclustra_mercury_aa1.dtsi"
+
+/* Select the boot mode: sd/mmc or qspi */
+//#include "socfpga_enclustra_mercury_aa1_qspi_boot.dtsi"
+#include "socfpga_enclustra_mercury_aa1_sdmmc_boot.dtsi"
+
+/* Select the carrier board */
+//#include "socfpga_enclustra_mercury_st1.dtsi"
+#include "socfpga_enclustra_mercury_pe1.dtsi"
+//#include "socfpga_enclustra_mercury_pe3.dtsi"
+
+/* Select the type of AA1 module */
+//#include "ME-AA1-270-2I2-D11E-NFX3.dtsi"
+//#include "ME-AA1-270-3E4-D11E-NFX3.dtsi"
+#include "ME-AA1-480-2I3-D12E-NFX3.dtsi"
diff --git a/arch/arm/dts/socfpga_arria10_mercury_aa1_handoff.h b/arch/arm/dts/socfpga_arria10_mercury_aa1_handoff.h
new file mode 100644
index 0000000000..46e7e3c18b
--- /dev/null
+++ b/arch/arm/dts/socfpga_arria10_mercury_aa1_handoff.h
@@ -0,0 +1,307 @@ 
+/* SPDX-License-Identifier: BSD-3-Clause */
+/*
+ * Intel Arria 10 SoCFPGA configuration
+ *
+ * Copyright (C) 2024 Enclustra GmbH
+ */
+
+#ifndef __SOCFPGA_ARRIA10_CONFIG_H__
+#define __SOCFPGA_ARRIA10_CONFIG_H__
+
+/* Clocks */
+#define CB_INTOSC_LS_CLK_HZ 60000000
+#define EMAC0_CLK_HZ 250000000
+#define EMAC1_CLK_HZ 250000000
+#define EMAC2_CLK_HZ 250000000
+#define EOSC1_CLK_HZ 33333000
+#define F2H_FREE_CLK_HZ 200000000
+#define H2F_USER0_CLK_HZ 100000000
+#define H2F_USER1_CLK_HZ 50000000
+#define L3_MAIN_FREE_CLK_HZ 400000000
+#define SDMMC_CLK_HZ 200000000
+#define TPIU_CLK_HZ 100000000
+#define MAINPLLGRP_CNTR15CLK_CNT 900
+#define MAINPLLGRP_CNTR2CLK_CNT 900
+#define MAINPLLGRP_CNTR3CLK_CNT 900
+#define MAINPLLGRP_CNTR4CLK_CNT 900
+#define MAINPLLGRP_CNTR5CLK_CNT 900
+#define MAINPLLGRP_CNTR6CLK_CNT 9
+#define MAINPLLGRP_CNTR7CLK_CNT 19
+#define MAINPLLGRP_CNTR7CLK_SRC 0
+#define MAINPLLGRP_CNTR8CLK_CNT 39
+#define MAINPLLGRP_CNTR9CLK_CNT 900
+#define MAINPLLGRP_CNTR9CLK_SRC 0
+#define MAINPLLGRP_MPUCLK_CNT 0
+#define MAINPLLGRP_MPUCLK_SRC 0
+#define MAINPLLGRP_NOCCLK_CNT 0
+#define MAINPLLGRP_NOCCLK_SRC 0
+#define MAINPLLGRP_NOCDIV_CSATCLK 0
+#define MAINPLLGRP_NOCDIV_CSPDBGCLK 1
+#define MAINPLLGRP_NOCDIV_CSTRACECLK 0
+#define MAINPLLGRP_NOCDIV_L4MAINCLK 0
+#define MAINPLLGRP_NOCDIV_L4MPCLK 1
+#define MAINPLLGRP_NOCDIV_L4SPCLK 2
+#define MAINPLLGRP_VCO0_PSRC 0
+#define MAINPLLGRP_VCO1_DENOM 32
+#define MAINPLLGRP_VCO1_NUMER 1980
+#define PERPLLGRP_CNTR2CLK_CNT 7
+#define PERPLLGRP_CNTR2CLK_SRC 1
+#define PERPLLGRP_CNTR3CLK_CNT 900
+#define PERPLLGRP_CNTR3CLK_SRC 1
+#define PERPLLGRP_CNTR4CLK_CNT 19
+#define PERPLLGRP_CNTR4CLK_SRC 1
+#define PERPLLGRP_CNTR5CLK_CNT 499
+#define PERPLLGRP_CNTR5CLK_SRC 1
+#define PERPLLGRP_CNTR6CLK_CNT 900
+#define PERPLLGRP_CNTR6CLK_SRC 0
+#define PERPLLGRP_CNTR7CLK_CNT 900
+#define PERPLLGRP_CNTR8CLK_CNT 900
+#define PERPLLGRP_CNTR8CLK_SRC 0
+#define PERPLLGRP_CNTR9CLK_CNT 900
+#define PERPLLGRP_EMACCTL_EMAC0SEL 0
+#define PERPLLGRP_EMACCTL_EMAC1SEL 0
+#define PERPLLGRP_EMACCTL_EMAC2SEL 0
+#define PERPLLGRP_GPIODIV_GPIODBCLK 32000
+#define PERPLLGRP_VCO0_PSRC 0
+#define PERPLLGRP_VCO1_DENOM 32
+#define PERPLLGRP_VCO1_NUMER 1980
+#define CLKMGR_TESTIOCTRL_DEBUGCLKSEL 16
+#define CLKMGR_TESTIOCTRL_MAINCLKSEL 8
+#define CLKMGR_TESTIOCTRL_PERICLKSEL 8
+#define ALTERAGRP_MPUCLK_MAINCNT 1
+#define ALTERAGRP_MPUCLK_PERICNT 900
+#define ALTERAGRP_NOCCLK_MAINCNT 4
+#define ALTERAGRP_NOCCLK_PERICNT 900
+#define ALTERAGRP_MPUCLK ((ALTERAGRP_MPUCLK_PERICNT << 16) | \
+	(ALTERAGRP_MPUCLK_MAINCNT))
+#define ALTERAGRP_NOCCLK ((ALTERAGRP_NOCCLK_PERICNT << 16) | \
+	(ALTERAGRP_NOCCLK_MAINCNT))
+
+/* Pin Mux Configuration */
+#define CONFIG_IO_10_INPUT_BUF_EN 1
+#define CONFIG_IO_10_PD_DRV_STRG 10
+#define CONFIG_IO_10_PD_SLW_RT 1
+#define CONFIG_IO_10_PU_DRV_STRG 8
+#define CONFIG_IO_10_PU_SLW_RT 1
+#define CONFIG_IO_10_RTRIM 1
+#define CONFIG_IO_10_WK_PU_EN 0
+#define CONFIG_IO_11_INPUT_BUF_EN 1
+#define CONFIG_IO_11_PD_DRV_STRG 10
+#define CONFIG_IO_11_PD_SLW_RT 1
+#define CONFIG_IO_11_PU_DRV_STRG 8
+#define CONFIG_IO_11_PU_SLW_RT 1
+#define CONFIG_IO_11_RTRIM 1
+#define CONFIG_IO_11_WK_PU_EN 0
+#define CONFIG_IO_12_INPUT_BUF_EN 1
+#define CONFIG_IO_12_PD_DRV_STRG 10
+#define CONFIG_IO_12_PD_SLW_RT 1
+#define CONFIG_IO_12_PU_DRV_STRG 8
+#define CONFIG_IO_12_PU_SLW_RT 1
+#define CONFIG_IO_12_RTRIM 1
+#define CONFIG_IO_12_WK_PU_EN 0
+#define CONFIG_IO_13_INPUT_BUF_EN 1
+#define CONFIG_IO_13_PD_DRV_STRG 10
+#define CONFIG_IO_13_PD_SLW_RT 1
+#define CONFIG_IO_13_PU_DRV_STRG 8
+#define CONFIG_IO_13_PU_SLW_RT 1
+#define CONFIG_IO_13_RTRIM 1
+#define CONFIG_IO_13_WK_PU_EN 0
+#define CONFIG_IO_14_INPUT_BUF_EN 1
+#define CONFIG_IO_14_PD_DRV_STRG 10
+#define CONFIG_IO_14_PD_SLW_RT 1
+#define CONFIG_IO_14_PU_DRV_STRG 8
+#define CONFIG_IO_14_PU_SLW_RT 1
+#define CONFIG_IO_14_RTRIM 1
+#define CONFIG_IO_14_WK_PU_EN 0
+#define CONFIG_IO_15_INPUT_BUF_EN 1
+#define CONFIG_IO_15_PD_DRV_STRG 10
+#define CONFIG_IO_15_PD_SLW_RT 1
+#define CONFIG_IO_15_PU_DRV_STRG 8
+#define CONFIG_IO_15_PU_SLW_RT 1
+#define CONFIG_IO_15_RTRIM 1
+#define CONFIG_IO_15_WK_PU_EN 0
+#define CONFIG_IO_16_INPUT_BUF_EN 0
+#define CONFIG_IO_16_PD_DRV_STRG 10
+#define CONFIG_IO_16_PD_SLW_RT 1
+#define CONFIG_IO_16_PU_DRV_STRG 8
+#define CONFIG_IO_16_PU_SLW_RT 1
+#define CONFIG_IO_16_RTRIM 1
+#define CONFIG_IO_16_WK_PU_EN 0
+#define CONFIG_IO_17_INPUT_BUF_EN 1
+#define CONFIG_IO_17_PD_DRV_STRG 10
+#define CONFIG_IO_17_PD_SLW_RT 1
+#define CONFIG_IO_17_PU_DRV_STRG 8
+#define CONFIG_IO_17_PU_SLW_RT 1
+#define CONFIG_IO_17_RTRIM 1
+#define CONFIG_IO_17_WK_PU_EN 0
+#define CONFIG_IO_1_INPUT_BUF_EN 1
+#define CONFIG_IO_1_PD_DRV_STRG 10
+#define CONFIG_IO_1_PD_SLW_RT 0
+#define CONFIG_IO_1_PU_DRV_STRG 8
+#define CONFIG_IO_1_PU_SLW_RT 0
+#define CONFIG_IO_1_RTRIM 1
+#define CONFIG_IO_1_WK_PU_EN 1
+#define CONFIG_IO_2_INPUT_BUF_EN 1
+#define CONFIG_IO_2_PD_DRV_STRG 10
+#define CONFIG_IO_2_PD_SLW_RT 0
+#define CONFIG_IO_2_PU_DRV_STRG 8
+#define CONFIG_IO_2_PU_SLW_RT 0
+#define CONFIG_IO_2_RTRIM 1
+#define CONFIG_IO_2_WK_PU_EN 1
+#define CONFIG_IO_3_INPUT_BUF_EN 1
+#define CONFIG_IO_3_PD_DRV_STRG 10
+#define CONFIG_IO_3_PD_SLW_RT 0
+#define CONFIG_IO_3_PU_DRV_STRG 8
+#define CONFIG_IO_3_PU_SLW_RT 0
+#define CONFIG_IO_3_RTRIM 1
+#define CONFIG_IO_3_WK_PU_EN 1
+#define CONFIG_IO_4_INPUT_BUF_EN 1
+#define CONFIG_IO_4_PD_DRV_STRG 10
+#define CONFIG_IO_4_PD_SLW_RT 1
+#define CONFIG_IO_4_PU_DRV_STRG 8
+#define CONFIG_IO_4_PU_SLW_RT 1
+#define CONFIG_IO_4_RTRIM 1
+#define CONFIG_IO_4_WK_PU_EN 0
+#define CONFIG_IO_5_INPUT_BUF_EN 1
+#define CONFIG_IO_5_PD_DRV_STRG 10
+#define CONFIG_IO_5_PD_SLW_RT 1
+#define CONFIG_IO_5_PU_DRV_STRG 8
+#define CONFIG_IO_5_PU_SLW_RT 1
+#define CONFIG_IO_5_RTRIM 1
+#define CONFIG_IO_5_WK_PU_EN 0
+#define CONFIG_IO_6_INPUT_BUF_EN 0
+#define CONFIG_IO_6_PD_DRV_STRG 10
+#define CONFIG_IO_6_PD_SLW_RT 1
+#define CONFIG_IO_6_PU_DRV_STRG 8
+#define CONFIG_IO_6_PU_SLW_RT 1
+#define CONFIG_IO_6_RTRIM 1
+#define CONFIG_IO_6_WK_PU_EN 0
+#define CONFIG_IO_7_INPUT_BUF_EN 1
+#define CONFIG_IO_7_PD_DRV_STRG 10
+#define CONFIG_IO_7_PD_SLW_RT 1
+#define CONFIG_IO_7_PU_DRV_STRG 8
+#define CONFIG_IO_7_PU_SLW_RT 1
+#define CONFIG_IO_7_RTRIM 1
+#define CONFIG_IO_7_WK_PU_EN 0
+#define CONFIG_IO_8_INPUT_BUF_EN 1
+#define CONFIG_IO_8_PD_DRV_STRG 10
+#define CONFIG_IO_8_PD_SLW_RT 1
+#define CONFIG_IO_8_PU_DRV_STRG 8
+#define CONFIG_IO_8_PU_SLW_RT 1
+#define CONFIG_IO_8_RTRIM 1
+#define CONFIG_IO_8_WK_PU_EN 0
+#define CONFIG_IO_9_INPUT_BUF_EN 1
+#define CONFIG_IO_9_PD_DRV_STRG 10
+#define CONFIG_IO_9_PD_SLW_RT 1
+#define CONFIG_IO_9_PU_DRV_STRG 8
+#define CONFIG_IO_9_PU_SLW_RT 1
+#define CONFIG_IO_9_RTRIM 1
+#define CONFIG_IO_9_WK_PU_EN 0
+#define CONFIG_IO_BANK_VOLTAGE_SEL_CLKRST_IO 1
+#define CONFIG_IO_BANK_VOLTAGE_SEL_PERI_IO 1
+#define PINMUX_DEDICATED_IO_10_SEL 15
+#define PINMUX_DEDICATED_IO_11_SEL 15
+#define PINMUX_DEDICATED_IO_12_SEL 15
+#define PINMUX_DEDICATED_IO_13_SEL 15
+#define PINMUX_DEDICATED_IO_14_SEL 15
+#define PINMUX_DEDICATED_IO_15_SEL 15
+#define PINMUX_DEDICATED_IO_16_SEL 13
+#define PINMUX_DEDICATED_IO_17_SEL 13
+#define PINMUX_DEDICATED_IO_4_SEL 8
+#define PINMUX_DEDICATED_IO_5_SEL 8
+#define PINMUX_DEDICATED_IO_6_SEL 8
+#define PINMUX_DEDICATED_IO_7_SEL 8
+#define PINMUX_DEDICATED_IO_8_SEL 8
+#define PINMUX_DEDICATED_IO_9_SEL 8
+#define PINMUX_I2C0_USEFPGA_SEL 0
+#define PINMUX_I2C1_USEFPGA_SEL 0
+#define PINMUX_I2CEMAC0_USEFPGA_SEL 0
+#define PINMUX_I2CEMAC1_USEFPGA_SEL 0
+#define PINMUX_I2CEMAC2_USEFPGA_SEL 0
+#define PINMUX_NAND_USEFPGA_SEL 0
+#define PINMUX_PLL_CLOCK_OUT_USEFPGA_SEL 0
+#define PINMUX_QSPI_USEFPGA_SEL 0
+#define PINMUX_RGMII0_USEFPGA_SEL 0
+#define PINMUX_RGMII1_USEFPGA_SEL 0
+#define PINMUX_RGMII2_USEFPGA_SEL 0
+#define PINMUX_SDMMC_USEFPGA_SEL 0
+#define PINMUX_SHARED_IO_Q1_10_SEL 8
+#define PINMUX_SHARED_IO_Q1_11_SEL 8
+#define PINMUX_SHARED_IO_Q1_12_SEL 8
+#define PINMUX_SHARED_IO_Q1_1_SEL 8
+#define PINMUX_SHARED_IO_Q1_2_SEL 8
+#define PINMUX_SHARED_IO_Q1_3_SEL 8
+#define PINMUX_SHARED_IO_Q1_4_SEL 8
+#define PINMUX_SHARED_IO_Q1_5_SEL 8
+#define PINMUX_SHARED_IO_Q1_6_SEL 8
+#define PINMUX_SHARED_IO_Q1_7_SEL 8
+#define PINMUX_SHARED_IO_Q1_8_SEL 8
+#define PINMUX_SHARED_IO_Q1_9_SEL 8
+#define PINMUX_SHARED_IO_Q2_10_SEL 4
+#define PINMUX_SHARED_IO_Q2_11_SEL 4
+#define PINMUX_SHARED_IO_Q2_12_SEL 4
+#define PINMUX_SHARED_IO_Q2_1_SEL 4
+#define PINMUX_SHARED_IO_Q2_2_SEL 4
+#define PINMUX_SHARED_IO_Q2_3_SEL 4
+#define PINMUX_SHARED_IO_Q2_4_SEL 4
+#define PINMUX_SHARED_IO_Q2_5_SEL 4
+#define PINMUX_SHARED_IO_Q2_6_SEL 4
+#define PINMUX_SHARED_IO_Q2_7_SEL 4
+#define PINMUX_SHARED_IO_Q2_8_SEL 4
+#define PINMUX_SHARED_IO_Q2_9_SEL 4
+#define PINMUX_SHARED_IO_Q3_10_SEL 15
+#define PINMUX_SHARED_IO_Q3_11_SEL 1
+#define PINMUX_SHARED_IO_Q3_12_SEL 1
+#define PINMUX_SHARED_IO_Q3_1_SEL 15
+#define PINMUX_SHARED_IO_Q3_2_SEL 15
+#define PINMUX_SHARED_IO_Q3_3_SEL 15
+#define PINMUX_SHARED_IO_Q3_4_SEL 15
+#define PINMUX_SHARED_IO_Q3_5_SEL 15
+#define PINMUX_SHARED_IO_Q3_6_SEL 15
+#define PINMUX_SHARED_IO_Q3_7_SEL 0
+#define PINMUX_SHARED_IO_Q3_8_SEL 0
+#define PINMUX_SHARED_IO_Q3_9_SEL 15
+#define PINMUX_SHARED_IO_Q4_10_SEL 15
+#define PINMUX_SHARED_IO_Q4_11_SEL 15
+#define PINMUX_SHARED_IO_Q4_12_SEL 15
+#define PINMUX_SHARED_IO_Q4_1_SEL 10
+#define PINMUX_SHARED_IO_Q4_2_SEL 10
+#define PINMUX_SHARED_IO_Q4_3_SEL 10
+#define PINMUX_SHARED_IO_Q4_4_SEL 10
+#define PINMUX_SHARED_IO_Q4_5_SEL 10
+#define PINMUX_SHARED_IO_Q4_6_SEL 10
+#define PINMUX_SHARED_IO_Q4_7_SEL 15
+#define PINMUX_SHARED_IO_Q4_8_SEL 15
+#define PINMUX_SHARED_IO_Q4_9_SEL 15
+#define PINMUX_SPIM0_USEFPGA_SEL 0
+#define PINMUX_SPIM1_USEFPGA_SEL 0
+#define PINMUX_SPIS0_USEFPGA_SEL 0
+#define PINMUX_SPIS1_USEFPGA_SEL 0
+#define PINMUX_UART0_USEFPGA_SEL 0
+#define PINMUX_UART1_USEFPGA_SEL 0
+#define PINMUX_USB0_USEFPGA_SEL 0
+#define PINMUX_USB1_USEFPGA_SEL 0
+
+/* Bridge Configuration */
+#define F2H_AXI_SLAVE 0
+#define F2SDRAM0_AXI_SLAVE 0
+#define F2SDRAM1_AXI_SLAVE 0
+#define F2SDRAM2_AXI_SLAVE 0
+#define H2F_AXI_MASTER 1
+#define LWH2F_AXI_MASTER 1
+
+/* Voltage Select for Config IO */
+#define CONFIG_IO_BANK_VSEL \
+	(((CONFIG_IO_BANK_VOLTAGE_SEL_CLKRST_IO & 0x3) << 8) | \
+	(CONFIG_IO_BANK_VOLTAGE_SEL_PERI_IO & 0x3))
+
+/* Macro for Config IO bit mapping */
+#define CONFIG_IO_MACRO(NAME) (((NAME ## _RTRIM & 0x7) << 19) | \
+	((NAME ## _INPUT_BUF_EN & 0x3) << 17) | \
+	((NAME ## _WK_PU_EN & 0x1) << 16) | \
+	((NAME ## _PU_SLW_RT & 0x1) << 13) | \
+	((NAME ## _PU_DRV_STRG & 0x1f) << 8) | \
+	((NAME ## _PD_SLW_RT & 0x1) << 5) | \
+	(NAME ## _PD_DRV_STRG & 0x1f))
+
+#endif /* __SOCFPGA_ARRIA10_CONFIG_H__ */
diff --git a/arch/arm/dts/socfpga_enclustra_mercury_aa1.dtsi b/arch/arm/dts/socfpga_enclustra_mercury_aa1.dtsi
new file mode 100644
index 0000000000..c3d468b01e
--- /dev/null
+++ b/arch/arm/dts/socfpga_enclustra_mercury_aa1.dtsi
@@ -0,0 +1,179 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+/ {
+	compatible = "altr,socfpga-arria10", "altr,socfpga";
+
+	aliases {
+		serial0 = &uart1;
+		ethernet0 = &gmac0;
+		spi0 = &qspi;
+		i2c0 = &i2c1;
+		i2c1 = &i2c0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	/* define i2c label to be used in baseboard dtsi */
+	soc {
+		i2c_encl: i2c@ffc02300 {
+		};
+		i2c_encl_fpga: i2c@ffc02200 {
+		};
+	};
+
+};
+
+&osc1 {
+	clock-frequency = <33330000>;
+};
+
+&l4_main_clk {
+	bootph-all;
+};
+
+&qspi_clk {
+	bootph-all;
+};
+
+&main_sdmmc_clk {
+	bootph-all;
+};
+
+&sdmmc_clk {
+	bootph-all;
+};
+
+&sdmmc_free_clk {
+	bootph-all;
+};
+
+&peri_sdmmc_clk {
+	bootph-all;
+};
+
+&uart1 {
+	bootph-all;
+	status = "okay";
+};
+
+&gpio1 {
+	status = "okay";
+};
+
+&gpio2 {
+	status = "okay";
+};
+
+&i2c_encl {
+	i2c-sda-hold-time-ns = <300>;
+	status = "okay";
+
+	clock-frequency = <100000>;
+
+	atsha204a: atsha204a@64 {
+		status = "okay";
+		compatible = "atmel,atsha204a";
+		reg = <0x64>;
+	};
+};
+
+&i2c_encl_fpga {
+	i2c-sda-hold-time-ns = <300>;
+	status = "disabled";
+};
+
+&mmc {
+	bootph-all;
+	status = "okay";
+	cap-sd-highspeed;
+	broken-cd;
+	bus-width = <4>;
+};
+
+&eccmgr {
+	sdmmca-ecc@ff8c2c00 {
+		compatible = "altr,socfpga-sdmmc-ecc";
+		reg = <0xff8c2c00 0x400>;
+		altr,ecc-parent = <&mmc>;
+		interrupts = <15 IRQ_TYPE_LEVEL_HIGH>,
+					 <47 IRQ_TYPE_LEVEL_HIGH>,
+					 <16 IRQ_TYPE_LEVEL_HIGH>,
+					 <48 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
+&qspi {
+	bootph-all;
+	status = "okay";
+
+	flash0: s25fl512s@0 {
+		bootph-all;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "spansion,s25fl512s", "jedec,spi-nor";
+		reg = <0>;
+
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
+		spi-max-frequency = <10000000>;
+
+		page-size = <256>;
+		block-size = <16>; /* 2^16, 64KB */
+		cdns,page-size = <256>;
+		cdns,block-size = <16>;
+		cdns,tshsl-ns = <200>;
+		cdns,tsd2d-ns = <255>;
+		cdns,tchsh-ns = <20>;
+		cdns,tslch-ns = <20>;
+	};
+};
+
+&watchdog1 {
+	bootph-all;
+	status = "disabled";
+};
+
+&gmac0 {
+	status = "okay";
+	/delete-property/ mac-address;
+	phy-mode = "rgmii";
+	phy-addr = <3>;
+	phy-handle = <&phy3>;
+
+	mdio0 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+
+		phy3: ethernet-phy@3 {
+			reg = <3>;
+
+			/* Add 2ns RX clock delay (1.2ns + 0.78ns)*/
+			rxc-skew-ps = <1680>;
+			rxd0-skew-ps = <420>;
+			rxd1-skew-ps = <420>;
+			rxd2-skew-ps = <420>;
+			rxd3-skew-ps = <420>;
+			rxdv-skew-ps = <420>;
+
+			/* Add 1.38ns TX clock delay (0.96ns + 0.42ns)*/
+			txc-skew-ps = <1860>;
+			txd0-skew-ps = <0>;
+			txd1-skew-ps = <0>;
+			txd2-skew-ps = <0>;
+			txd3-skew-ps = <0>;
+			txen-skew-ps = <0>;
+		};
+	};
+};
+
+&usb0 {
+	status = "okay";
+	dr_mode = "host";
+};
+
diff --git a/arch/arm/dts/socfpga_enclustra_mercury_aa1_qspi_boot.dtsi b/arch/arm/dts/socfpga_enclustra_mercury_aa1_qspi_boot.dtsi
new file mode 100644
index 0000000000..f51dc7c55f
--- /dev/null
+++ b/arch/arm/dts/socfpga_enclustra_mercury_aa1_qspi_boot.dtsi
@@ -0,0 +1,18 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+/ {
+	fs_loader0: fs-loader {
+		bootph-all;
+		compatible = "u-boot,fs-loader";
+		sfconfig = <0 0 50000000 3>;
+	};
+};
+
+&fpga_mgr {
+	bootph-all;
+	firmware-loader = <&fs_loader0>;
+	altr,bitstream = "300000";
+};
diff --git a/arch/arm/dts/socfpga_enclustra_mercury_aa1_sdmmc_boot.dtsi b/arch/arm/dts/socfpga_enclustra_mercury_aa1_sdmmc_boot.dtsi
new file mode 100644
index 0000000000..052726e318
--- /dev/null
+++ b/arch/arm/dts/socfpga_enclustra_mercury_aa1_sdmmc_boot.dtsi
@@ -0,0 +1,18 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+/ {
+	fs_loader0: fs-loader {
+		bootph-all;
+		compatible = "u-boot,fs-loader";
+		phandlepart = <&mmc 1>;
+	};
+};
+
+&fpga_mgr {
+	bootph-all;
+	firmware-loader = <&fs_loader0>;
+	altr,bitstream = "bitstream.itb";
+};
diff --git a/arch/arm/dts/socfpga_enclustra_mercury_pe1.dtsi b/arch/arm/dts/socfpga_enclustra_mercury_pe1.dtsi
new file mode 100644
index 0000000000..e39474f443
--- /dev/null
+++ b/arch/arm/dts/socfpga_enclustra_mercury_pe1.dtsi
@@ -0,0 +1,7 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+/ {
+};
diff --git a/arch/arm/dts/socfpga_enclustra_mercury_pe3.dtsi b/arch/arm/dts/socfpga_enclustra_mercury_pe3.dtsi
new file mode 100644
index 0000000000..85d5050bb1
--- /dev/null
+++ b/arch/arm/dts/socfpga_enclustra_mercury_pe3.dtsi
@@ -0,0 +1,8 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+&i2c_encl_fpga {
+	status = "okay";
+};
diff --git a/arch/arm/dts/socfpga_enclustra_mercury_st1.dtsi b/arch/arm/dts/socfpga_enclustra_mercury_st1.dtsi
new file mode 100644
index 0000000000..85d5050bb1
--- /dev/null
+++ b/arch/arm/dts/socfpga_enclustra_mercury_st1.dtsi
@@ -0,0 +1,8 @@ 
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2024 Enclustra GmbH - https://www.enclustra.com
+ */
+
+&i2c_encl_fpga {
+	status = "okay";
+};