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

[Lothar Rubusch]

Dear U-boot community!

On Mon, Oct 7, 2024 at 12:21 PM Sumit Garg <sumit.garg at linaro.org> wrote:
>
> On Sat, 5 Oct 2024 at 07:14, Marek Vasut <marex at 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 at 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