-----Original Message-----
From: Lothar Rubusch <l.rubu...@gmail.com>
Sent: Monday, January 27, 2025 6:24 PM
To: Chee, Tien Fong <tien.fong.c...@intel.com>
Cc: u-boot@lists.denx.de; tr...@konsulko.com; ma...@denx.de;
simon.k.r.goldschm...@gmail.com; sumit.g...@linaro.org; s...@chromium.org;
xypron.g...@gmx.de; michal.si...@amd.com; Lim, Jit Loon
<jit.loon....@intel.com>; bar...@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.c...@intel.com>
wrote:
>
> Hi,
>
Dear Tien Fong Chee,
> -----Original Message-----
> From: Lothar Rubusch <l.rubu...@gmail.com>
> Sent: Saturday, October 26, 2024 11:52 PM
> To: u-boot@lists.denx.de; tr...@konsulko.com; ma...@denx.de;
> simon.k.r.goldschm...@gmail.com; Chee, Tien Fong
> <tien.fong.c...@intel.com>; sumit.g...@linaro.org
> Cc: s...@chromium.org; xypron.g...@gmx.de; michal.si...@amd.com; Lim,
> Jit Loon <jit.loon....@intel.com>; bar...@google.com;
> l.rubu...@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.buerk...@enclustra.com>
> Signed-off-by: Lothar Rubusch <l.rubu...@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.rubu...@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
