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

[Chee, Tien Fong]

-----Original Message-----
From: Lothar Rubusch <l.rubusch at gmail.com> 
Sent: Monday, January 27, 2025 6:24 PM
To: Chee, Tien Fong <tien.fong.chee at intel.com>
Cc: u-boot at lists.denx.de; trini at konsulko.com; marex at denx.de; simon.k.r.goldschmidt at gmail.com; sumit.garg at linaro.org; 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
Subject: Re: [PATCH v4 03/11] ARM: dts: socfpga: add Mercury+ AA1 for u-boot dts

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