> -----Original Message----- > From: Lothar Rubusch <[email protected]> > Sent: Sunday, March 9, 2025 10:36 PM > To: Chee, Tien Fong <[email protected]> > Cc: Chee, Tien Fong <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; Lim, Jit Loon <[email protected]>; > [email protected]; Ang, Tien Sung <[email protected]> > 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 > <[email protected]> wrote: > > > > Dear Lothar, > > > > > -----Original Message----- > > > From: Chee, Tien Fong <[email protected]> > > > Sent: Monday, March 3, 2025 11:05 AM > > > To: Lothar Rubusch <[email protected]> > > > Cc: [email protected]; [email protected]; [email protected]; > > > [email protected]; [email protected]; > > > [email protected]; [email protected]; [email protected]; Lim, > Jit > > > Loon <[email protected]>; [email protected]; Chee, Tien Fong > > > <[email protected]> > > > Subject: RE: [PATCH v4 03/11] ARM: dts: socfpga: add Mercury+ AA1 > > > for u- boot dts > > > > > > > > > > > > -----Original Message----- > > > From: Lothar Rubusch <[email protected]> > > > Sent: Monday, January 27, 2025 6:24 PM > > > To: Chee, Tien Fong <[email protected]> > > > Cc: [email protected]; [email protected]; [email protected]; > > > [email protected]; [email protected]; > > > [email protected]; [email protected]; [email protected]; Lim, > Jit > > > Loon <[email protected]>; [email protected] > > > 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 > > > <[email protected]> > > > wrote: > > > > > > > > Hi, > > > > > > > > > > Dear Tien Fong Chee, > > > > > > > -----Original Message----- > > > > From: Lothar Rubusch <[email protected]> > > > > Sent: Saturday, October 26, 2024 11:52 PM > > > > To: [email protected]; [email protected]; [email protected]; > > > > [email protected]; Chee, Tien Fong > > > > <[email protected]>; [email protected] > > > > Cc: [email protected]; [email protected]; [email protected]; > > > > Lim, Jit Loon <[email protected]>; [email protected]; > > > > [email protected] > > > > 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 <[email protected]> > > > > Signed-off-by: Lothar Rubusch <[email protected]> > > > > --- > > > > ..._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 <[email protected]> */ > > > > + > > > > +/* 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 [email protected], 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
