[PATCH v4 03/11] ARM: dts: socfpga: add Mercury+ AA1 for u-boot dts

[Lothar Rubusch]

On Tue, Jan 21, 2025 at 11:03 AM Chee, Tien Fong
<tien.fong.chee at intel.com> wrote:
>
> Hi,
>

Dear Tien Fong Chee,

> -----Original Message-----
> From: Lothar Rubusch <l.rubusch at gmail.com>
> Sent: Saturday, October 26, 2024 11:52 PM
> To: u-boot at lists.denx.de; trini at konsulko.com; marex at denx.de; simon.k.r.goldschmidt at gmail.com; Chee, Tien Fong <tien.fong.chee at intel.com>; sumit.garg at linaro.org
> Cc: sjg at chromium.org; xypron.glpk at gmx.de; michal.simek at amd.com; Lim, Jit Loon <jit.loon.lim at intel.com>; barnas at google.com; l.rubusch at gmail.com
> Subject: [PATCH v4 03/11] ARM: dts: socfpga: add Mercury+ AA1 for u-boot dts
>
> Introduce u-boot specific device-tree files for Enclustra Mercury+ AA1 SoMs (Intel/arria10).
>
> Generic device-tree fragments for linux and U-boot shall be provided in dts/upstream. The selection of the generic device-tree fragments depends on a selected boot-mode and a selected carrier board.
>
> On Intel/Arria10 a handoff setup is needed for initialization of various clock / pinmux / DRAM settings only used by U-Boot provided by the current patch.
>
> Signed-off-by: Andreas Buerkler <andreas.buerkler at enclustra.com>
> Signed-off-by: Lothar Rubusch <l.rubusch at gmail.com>
> ---
>  ..._arria10_enclustra_mercury_aa1-u-boot.dtsi |  45 +++  .../socfpga_arria10_enclustra_mercury_aa1.dts |  45 +++
>  .../socfpga_arria10_mercury_aa1-u-boot.dtsi   |  19 ++
>  .../dts/socfpga_arria10_mercury_aa1_handoff.h | 305 ++++++++++++++++++
>  board/enclustra/mercury_aa1/Kconfig           |  37 +++
>  board/enclustra/mercury_aa1/MAINTAINERS       |   2 +
>  6 files changed, 453 insertions(+)
>  create mode 100644 arch/arm/dts/socfpga_arria10_enclustra_mercury_aa1-u-boot.dtsi
>  create mode 100644 arch/arm/dts/socfpga_arria10_enclustra_mercury_aa1.dts
>  create mode 100644 arch/arm/dts/socfpga_arria10_mercury_aa1_handoff.h
>
> diff --git a/arch/arm/dts/socfpga_arria10_enclustra_mercury_aa1-u-boot.dtsi b/arch/arm/dts/socfpga_arria10_enclustra_mercury_aa1-u-boot.dtsi
> new file mode 100644
> index 0000000000..6e38286572
> --- /dev/null
> +++ b/arch/arm/dts/socfpga_arria10_enclustra_mercury_aa1-u-boot.dtsi
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Copyright (C) 2024 Lothar Rubusch <l.rubusch at gmail.com>  */
> +
> +/* Arria10 handoff (u-boot) */
> +#include "socfpga_arria10_mercury_aa1_handoff.h"
> +#include "socfpga_arria10-handoff.dtsi"
> +#include "socfpga_arria10_handoff_u-boot.dtsi"
> +#include "socfpga_arria10_mercury_aa1-u-boot.dtsi"
> +
> +/* Specific boot-mode (u-boot) */
> +#if IS_ENABLED(CONFIG_ENCLUSTRA_SDMMC) ||
> +IS_ENABLED(CONFIG_ENCLUSTRA_EMMC)
> +
> +/ {
> +       fs_loader0: fs-loader {
> +               bootph-all;
> +               compatible = "u-boot,fs-loader";
> +               phandlepart = <&mmc 1>;
> +       };
> +};
> +
> +&fpga_mgr {
> +       bootph-all;
> +       firmware-loader = <&fs_loader0>;
> +       altr,bitstream = "fpga.itb";
> +};
> +
> +#elif IS_ENABLED(CONFIG_ENCLUSTRA_QSPI)
> +
> +/ {
> +       fs_loader0: fs-loader {
> +               bootph-all;
> +               compatible = "u-boot,fs-loader";
> +               sfconfig = <0 0 50000000 3>;
>
> The RAW read implementation in fs_loader is not upstream yet, I afraid this might not working, you want help to upstream?
>

Thank you so much for coming back to me! The TL;DR answer is, yes.
Pls, start by fixing Intel platform maintenance in the Linux kernel
for old Intel/socfpga.

For the long story, there are several points here which are probably
not quite transparent just on u-boot ML. Let me clarify. Personally, I
have access to some Enclustra hardware and was curious what it would
take to upstream it. This was/is driven mainly by my private interest,
since the company gives a ...does not care about open source. As you
will easily spot those Intel platforms are not the most recent Intel
products either. I picked them a bit on purpose, since I did not want
to "mess it up" for that company with my personal upstream in the
first approach. If it went upstream, it could be the basis for further
Enclustra Hardware i.e. Xilinx/AMD, Microchip and more recent Intel.
That's a bit the background and intention.

So, when I started last summer, u-boot community stared with dts
upstream. Means, my DTS material needed to be prepared and split up
into a linux kernel part and a u-boot part. Due to the bitstream
handling and early initialization of registers, also, the u-boot DTS
went partly into dts-upstream, and partly into the classic DTS places
for he intel/socfpga platform. I managed to implement a dynamically
adjusted Enclustra DTS, based kconfig option. At the end of the day,
this all resulted in the dependency to have DTS material upstream in
the linux kernel repo.

Both patchsets were actually prepared and presented on the MLs. For
u-boot, you will find all communication concerning the u-boot patches
here on this ML. Where for the kernel patches, I got the more general
patches ACK'd. But the Intel maintainer Dinh Nguyen did not manage to
give feedback. I was even able to contact Dinh directly, and he gave
me back that he plans on doing. This was in fall 2024. No update since
then. - Here is, IMHO, where you Intel guys could really help work on
solving this situation: Either help out Dinh for the kernel stuff, or
organize replacement. Don't get me wrong, this is not meant to be
personal. I'm sure he will have good reasons if he cannot carry out
this job currently. Means put up someone who will (co-)maintain the
old Intel platforms in the Linux kernel. Also, the Intel/socfpga
dt-bindings need to be written in YAML, AFAIR. That's why e.g. Rob's
DT-check bot will almost blast you with errors with the comment "can
be accepted if the specific platform maintainer is willing to".
Platform maintainer does not answer, and I'm not willing writing the
YAML dt-bindings for ye olde Intel, when there is no maintainer
eventually accepting it.. Hence, accepting the Enclustra Intel DTS,
would mean to accept them w/o the updated and checked dt-bindings.

For the (technical) rest: I have full access to the hardware, i.e. 3
different Arria10 SOMs of Enclustra, as 2 further Cyclone5 SOMs. All
can be combined with 3 different carrier boards of Enclustra. The
setups are booting in different boot modes (SD, eMMC and some from
QSPI flash). After the DTS separation, (re)implementing the
mini-drivers based on u-boot DM, I needed to migrate the setup using
binman. Building, flashing and booting into a functional u-boot, is
verified for all setups. As you mentioned, parts in the u-boot API
are/were still under development, though, but Marek kept me in the
loop here (also on ML).

I appreciate your patience, for reading this all. In a conclusion, the
products are still sold. Yes, they are a bit ancient.. what eventually
blocked it, is IMHO rather kenel maintenance for old Intel platforms
which seems orphaned. For me personally, it already paid off a lot
from what I could learn! - Yes, I'd love to see the stuff upstream.
There seems to be less love by Intel, though, for its socfpga
platforms on Linux. ;)

Best,
L


> [...]
>
> Best regards,
> TF