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

Sun Mar 9 15:36:29 CET 2025

Dear Tien Fong, thank you so much. Please find my answer inlined below.

On Mon, Mar 3, 2025 at 4:35 AM Chee, Tien Fong
<tien.fong.chee at altera.com> wrote:
>
> Dear Lothar,
>
> > -----Original Message-----
> > From: Chee, Tien Fong <tien.fong.chee at intel.com>
> > Sent: Monday, March 3, 2025 11:05 AM
> > To: Lothar Rubusch <l.rubusch at gmail.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; Chee, Tien Fong
> > <tien.fong.chee at altera.com>
> > Subject: RE: [PATCH v4 03/11] ARM: dts: socfpga: add Mercury+ AA1 for u-
> > boot dts
> >
> >
> >
> > -----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. ;)
>
> Sorry for the late response, I have been following up on this with Kernel team, the transferring ownership is already kicking off, probably Q3 at the earliest. The team is also working on upstreaming the fixes to schema check failures, primarily converting old text version of device tree bindings to yaml.
>
> I will update more once I have more information from them.

Tien Fong, I highly appreciate coming back to me and letting me know.

Is there a possibility to contribute and help out converting old text
files to YAML and/or fixing the schema check failures? This is a huge
possibility for me to learn. If so, just let me know, who would be
maintainer to be put in CC for the patches (probably mostly on kernel
side).

Anyway, let's see during the year.
Best regards,
L

>
> Thanks.
>
> Best regards,
> Tien Fong
>
> >
> > Best,
> > L
> >
> >
> > > [...]
> > >
> > > Best regards,
> > > TF