[PATCH v4 03/11] ARM: dts: socfpga: add Mercury+ AA1 for u-boot dts
Chee, Tien Fong
tien.fong.chee at altera.com
Thu Mar 27 08:44:18 CET 2025
> -----Original Message-----
> From: Lothar Rubusch <l.rubusch at gmail.com>
> Sent: Sunday, March 9, 2025 10:36 PM
> To: Chee, Tien Fong <tien.fong.chee at altera.com>
> Cc: Chee, Tien Fong <tien.fong.chee at intel.com>; 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; Ang, Tien Sung <tien.sung.ang at altera.com>
> Subject: Re: [PATCH v4 03/11] ARM: dts: socfpga: add Mercury+ AA1 for u-
> boot dts
>
> 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.dt
> > > > +++ si
> > > > @@ -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).
Sure. Adding Matthew matthew.gerlach at altera.com, he will be our SoCFPGA maintainer for Kernel.
>
> Anyway, let's see during the year.
> Best regards,
> L
>
> >
> > Thanks.
> >
> > Best regards,
> > Tien Fong
> >
> > >
> > > Best,
> > > L
> > >
> > >
> > > > [...]
> > > >
> > > > Best regards,
> > > > TF
More information about the U-Boot
mailing list