[PATCH v1 0/8]SoCFPGA: Update Boot Support for CycloneV in U-Boot

[PATCH v1 0/8]SoCFPGA: Update Boot Support for CycloneV in U-Boot

[alif.zakuan.yuslaimi]

From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>

This patch set updates the boot support for the Altera SoCFPGA CycloneV platform in U-Boot. The changes include:
	1. Board-specific configurations and setup required to enable CycloneV multiboot operation in U-Boot.
	2. Migration from raw to FAT mode for SPL MMC boot
	3. Backwards compatibility support for legacy SoCFPGA devices to enable/disable SDMMC clock in common SoCFPGA MMC driver.

This patch set has been tested on CycloneV devkit with SDMMC boot and RAM boot (TFTP & ARM DS debugger).

Alif Zakuan Yuslaimi (7):
  configs: cyclone5: Disable mkeficapsule tool build
  configs: cyclone5: Enable random MAC address
  mmc: socfpga_dw_mmc: Restore legacy clkmgr address retrieval
  spl: Remove ARCH_SOCFPGA from MMC raw mode enablement
  configs: cyclone5: Enable SPL FAT support
  configs: cyclone5: Update boot command for CycloneV
  configs: cyclone5: Disable SPI in SPL

Tien Fong Chee (1):
  arm: Fix "file truncated" linker errors from empty built-in.a in
    SPL/TPL/VPL builds

 arch/arm/cpu/Makefile              |  2 +-
 arch/arm/cpu/dummy.c               |  7 +++++
 cmd/Makefile                       |  4 ++-
 cmd/dummy.c                        |  7 +++++
 common/spl/Kconfig                 |  4 +--
 configs/socfpga_cyclone5_defconfig |  8 +++++-
 disk/Makefile                      |  5 ++++
 disk/dummy.c                       |  7 +++++
 drivers/mmc/socfpga_dw_mmc.c       | 46 +++++++++++++++++++-----------
 dts/Makefile                       |  5 ++++
 dts/dummy.c                        |  7 +++++
 env/Makefile                       |  5 ++++
 env/dummy.c                        |  7 +++++
 13 files changed, 93 insertions(+), 21 deletions(-)
 create mode 100644 arch/arm/cpu/dummy.c
 create mode 100644 cmd/dummy.c
 create mode 100644 disk/dummy.c
 create mode 100644 dts/dummy.c
 create mode 100644 env/dummy.c

-- 
2.43.7

[PATCH v1 1/8] configs: cyclone5: Disable mkeficapsule tool build

[alif.zakuan.yuslaimi]

From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>

mkeficapsule tool will be built by default if EFI_LOADER is set due to
commit b7a625b1ce49 ("tools: Build mkeficapsule tool by default if
EFI_LOADER is set").

This will cause compilation error on all our SoCFPGA devices, hence we will
be disabling this config as we do not utilize this tool.

Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
---
 configs/socfpga_cyclone5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
index fef4cb90516..4a6f9b336cb 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -79,3 +79,4 @@ CONFIG_USB_GADGET_DWC2_OTG=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 # CONFIG_SPL_WDT is not set
 CONFIG_SYS_TIMER_COUNTS_DOWN=y
+# CONFIG_TOOLS_MKEFICAPSULE is not set
-- 
2.43.7

Re: [PATCH v1 1/8] configs: cyclone5: Disable mkeficapsule tool build

[Chee, Tien Fong]

On 25/11/2025 4:13 pm, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>
> mkeficapsule tool will be built by default if EFI_LOADER is set due to
> commit b7a625b1ce49 ("tools: Build mkeficapsule tool by default if
> EFI_LOADER is set").
>
> This will cause compilation error on all our SoCFPGA devices, hence we will
> be disabling this config as we do not utilize this tool.
>
> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> ---
>   configs/socfpga_cyclone5_defconfig | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
> index fef4cb90516..4a6f9b336cb 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -79,3 +79,4 @@ CONFIG_USB_GADGET_DWC2_OTG=y
>   CONFIG_USB_GADGET_DOWNLOAD=y
>   # CONFIG_SPL_WDT is not set
>   CONFIG_SYS_TIMER_COUNTS_DOWN=y
> +# CONFIG_TOOLS_MKEFICAPSULE is not set


Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>

Best regards,
Tien Fong

[PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[alif.zakuan.yuslaimi]

From: Tien Fong Chee <tien.fong.chee@intel.com>

When building 32-bit ARM SPL (e.g. Arria 10), linking may fail with:

    arch/arm/cpu/built-in.a: file not recognized: File truncated
    cmd/built-in.a: file not recognized: File truncated
    dts/built-in.a: file not recognized: File truncated

This happens when a directory (such as arch/arm/cpu/, cmd/, or dts/)
produces no object files under SPL. GNU `ar` still creates a zero-length
archive, which older ARM 32-bit linkers (arm-linux-gnueabihf-ld) treat as
invalid. The final link step then aborts with the "file truncated" error.

By contrast, 64-bit SoCFPGA (Agilex 5) builds use aarch64 linkers that
tolerate empty thin archives, so the same condition does not cause an
error.

To make XPL (SPL/TPL/VPL) builds consistent across architectures, this
patch ensures each affected directory always contributes at least one valid
object:

  * `arch/arm/cpu/Makefile` — add a persistent `dummy.o`
  * `cmd/Makefile` — add `dummy.o` only when CONFIG_XPL_BUILD=y
  * `dts/Makefile` — add `dummy.o` only when CONFIG_XPL_BUILD=y

These dummy objects define no functional code and do not affect runtime
behavior. They only guarantee a valid archive for the linker, preventing
false "file truncated" errors on strict toolchains.

Signed-off-by: Tien Fong Chee <tien.fong.chee@altera.com>
Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
---
 arch/arm/cpu/Makefile | 2 +-
 arch/arm/cpu/dummy.c  | 7 +++++++
 cmd/Makefile          | 4 +++-
 cmd/dummy.c           | 7 +++++++
 disk/Makefile         | 5 +++++
 disk/dummy.c          | 7 +++++++
 dts/Makefile          | 5 +++++
 dts/dummy.c           | 7 +++++++
 env/Makefile          | 5 +++++
 env/dummy.c           | 7 +++++++
 10 files changed, 54 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/cpu/dummy.c
 create mode 100644 cmd/dummy.c
 create mode 100644 disk/dummy.c
 create mode 100644 dts/dummy.c
 create mode 100644 env/dummy.c

diff --git a/arch/arm/cpu/Makefile b/arch/arm/cpu/Makefile
index a0e1c2a651d..fc409bc5a90 100644
--- a/arch/arm/cpu/Makefile
+++ b/arch/arm/cpu/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0+
 
-obj- += dummy.o
+obj-y += dummy.o
diff --git a/arch/arm/cpu/dummy.c b/arch/arm/cpu/dummy.c
new file mode 100644
index 00000000000..a7a55a02c20
--- /dev/null
+++ b/arch/arm/cpu/dummy.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2025 Altera Corporation <www.altera.com>
+ */
+
+void __arch_arm_cpu_dummy(void) { }
+
diff --git a/cmd/Makefile b/cmd/Makefile
index 25479907797..104e8a770e7 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -3,7 +3,9 @@
 # (C) Copyright 2004-2006
 # Wolfgang Denk, DENX Software Engineering, wd@denx.de.
 
-ifndef CONFIG_XPL_BUILD
+ifdef CONFIG_XPL_BUILD
+obj-y += dummy.o
+else
 # core command
 obj-y += boot.o
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
diff --git a/cmd/dummy.c b/cmd/dummy.c
new file mode 100644
index 00000000000..a4d10f413bc
--- /dev/null
+++ b/cmd/dummy.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2025 Altera Corporation <www.altera.com>
+ */
+
+void __cmd_dummy_placeholder(void) {}
+
diff --git a/disk/Makefile b/disk/Makefile
index 2248a659f8b..eb17dac8b67 100644
--- a/disk/Makefile
+++ b/disk/Makefile
@@ -18,3 +18,8 @@ obj-$(CONFIG_$(PHASE_)ISO_PARTITION)   += part_iso.o
 obj-$(CONFIG_$(PHASE_)AMIGA_PARTITION) += part_amiga.o
 obj-$(CONFIG_$(PHASE_)EFI_PARTITION)   += part_efi.o
 endif
+
+# Avoid empty dts/built-in.a during SPL/TPL/VPL builds
+ifdef CONFIG_XPL_BUILD
+obj-y += dummy.o
+endif
diff --git a/disk/dummy.c b/disk/dummy.c
new file mode 100644
index 00000000000..0d7d99f744e
--- /dev/null
+++ b/disk/dummy.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2025 Altera Corporation <www.altera.com>
+ */
+
+void __disk_dummy_placeholder(void) {}
+
diff --git a/dts/Makefile b/dts/Makefile
index fd4ae31a533..1bf5577b403 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -89,3 +89,8 @@ subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/d
 	   ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts	\
 	   ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts	\
 	   ./upstream/src/arm64 ./upstream/src/$(ARCH)
+
+# Avoid empty dts/built-in.a during SPL/TPL/VPL builds
+ifdef CONFIG_XPL_BUILD
+obj-y += dummy.o
+endif
diff --git a/dts/dummy.c b/dts/dummy.c
new file mode 100644
index 00000000000..8007239d3f6
--- /dev/null
+++ b/dts/dummy.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2025 Altera Corporation <www.altera.com>
+ */
+
+void __dts_dummy_placeholder(void) {}
+
diff --git a/env/Makefile b/env/Makefile
index d11b87702c1..4ebb6018b4a 100644
--- a/env/Makefile
+++ b/env/Makefile
@@ -31,3 +31,8 @@ obj-$(CONFIG_$(PHASE_)ENV_IS_IN_FLASH) += flash.o
 obj-$(CONFIG_$(PHASE_)ENV_IS_IN_SCSI) += scsi.o
 
 CFLAGS_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 2>/dev/null)
+
+# Avoid empty dts/built-in.a during SPL/TPL/VPL builds
+ifdef CONFIG_XPL_BUILD
+obj-y += dummy.o
+endif
diff --git a/env/dummy.c b/env/dummy.c
new file mode 100644
index 00000000000..dc23f8439d0
--- /dev/null
+++ b/env/dummy.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2025 Altera Corporation <www.altera.com>
+ */
+
+void __env_dummy_placeholder(void) {}
+
-- 
2.43.7

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Marek Vasut]

On 11/25/25 9:13 AM, alif.zakuan.yuslaimi@altera.com wrote:
> From: Tien Fong Chee <tien.fong.chee@intel.com>
> 
> When building 32-bit ARM SPL (e.g. Arria 10), linking may fail with:
> 
>      arch/arm/cpu/built-in.a: file not recognized: File truncated
>      cmd/built-in.a: file not recognized: File truncated
>      dts/built-in.a: file not recognized: File truncated
> 
> This happens when a directory (such as arch/arm/cpu/, cmd/, or dts/)
> produces no object files under SPL. GNU `ar` still creates a zero-length
> archive, which older ARM 32-bit linkers (arm-linux-gnueabihf-ld) treat as
> invalid. The final link step then aborts with the "file truncated" error.
> 
> By contrast, 64-bit SoCFPGA (Agilex 5) builds use aarch64 linkers that
> tolerate empty thin archives, so the same condition does not cause an
> error.
> 
> To make XPL (SPL/TPL/VPL) builds consistent across architectures, this
> patch ensures each affected directory always contributes at least one valid
> object:
> 
>    * `arch/arm/cpu/Makefile` — add a persistent `dummy.o`
>    * `cmd/Makefile` — add `dummy.o` only when CONFIG_XPL_BUILD=y
>    * `dts/Makefile` — add `dummy.o` only when CONFIG_XPL_BUILD=y
> 
> These dummy objects define no functional code and do not affect runtime
> behavior. They only guarantee a valid archive for the linker, preventing
> false "file truncated" errors on strict toolchains.
> 
> Signed-off-by: Tien Fong Chee <tien.fong.chee@altera.com>
> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
Such generic fixes should not be buried in SoC specific series.

+CC Tom

Maybe you need a fix similar to

37a777e1286e ("Makefile: Make sure all linker input objects exist")

?

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Yuslaimi, Alif Zakuan]

Hi Marek,

On 25/11/2025 8:23 pm, Marek Vasut wrote:
> [CAUTION: This email is from outside your organization. Unless you trust 
> the sender, do not click on links or open attachments as it may be a 
> fraudulent email attempting to steal your information and/or compromise 
> your computer.]
> 
> On 11/25/25 9:13 AM, alif.zakuan.yuslaimi@altera.com wrote:
>> From: Tien Fong Chee <tien.fong.chee@intel.com>
>>
>> When building 32-bit ARM SPL (e.g. Arria 10), linking may fail with:
>>
>>      arch/arm/cpu/built-in.a: file not recognized: File truncated
>>      cmd/built-in.a: file not recognized: File truncated
>>      dts/built-in.a: file not recognized: File truncated
>>
>> This happens when a directory (such as arch/arm/cpu/, cmd/, or dts/)
>> produces no object files under SPL. GNU `ar` still creates a zero-length
>> archive, which older ARM 32-bit linkers (arm-linux-gnueabihf-ld) treat as
>> invalid. The final link step then aborts with the "file truncated" error.
>>
>> By contrast, 64-bit SoCFPGA (Agilex 5) builds use aarch64 linkers that
>> tolerate empty thin archives, so the same condition does not cause an
>> error.
>>
>> To make XPL (SPL/TPL/VPL) builds consistent across architectures, this
>> patch ensures each affected directory always contributes at least one 
>> valid
>> object:
>>
>>    * `arch/arm/cpu/Makefile` — add a persistent `dummy.o`
>>    * `cmd/Makefile` — add `dummy.o` only when CONFIG_XPL_BUILD=y
>>    * `dts/Makefile` — add `dummy.o` only when CONFIG_XPL_BUILD=y
>>
>> These dummy objects define no functional code and do not affect runtime
>> behavior. They only guarantee a valid archive for the linker, preventing
>> false "file truncated" errors on strict toolchains.
>>
>> Signed-off-by: Tien Fong Chee <tien.fong.chee@altera.com>
>> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> Such generic fixes should not be buried in SoC specific series.
> 
> +CC Tom
> 
> Maybe you need a fix similar to
> 
> 37a777e1286e ("Makefile: Make sure all linker input objects exist")
> 
> ?

I already have the referenced commit in my test branch, and I can 
confirm that the same compilation error still appears on CycloneV when 
certain directories produce no SPL objects.

The existing fix ensures that built-in.o is always present, but it does 
not prevent ar from generating empty built-in.a archives, which older 
ARM 32-bit linkers (such as CycloneV toolchains) reject as “file truncated”.

This patch complements the earlier fix by ensuring that each SPL 
directory contributes at least one real object, so the resulting 
built-in.a archives are non-empty and accepted by all toolchains. It 
does not change runtime behavior—only ensures the archives remain valid.

Thanks,
Alif

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Marek Vasut]

On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:

Hello everyone,

> I already have the referenced commit in my test branch, and I can 
> confirm that the same compilation error still appears on CycloneV when 
> certain directories produce no SPL objects.
> 
> The existing fix ensures that built-in.o is always present, but it does 
> not prevent ar from generating empty built-in.a archives, which older 
> ARM 32-bit linkers (such as CycloneV toolchains) reject as “file 
> truncated”.

Which toolchain is this ?

> This patch complements the earlier fix by ensuring that each SPL 
> directory contributes at least one real object, so the resulting built- 
> in.a archives are non-empty and accepted by all toolchains. It does not 
> change runtime behavior—only ensures the archives remain valid.
> 
> Thanks,
> Alif
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Yuslaimi, Alif Zakuan]

On 27/11/2025 11:09 pm, Marek Vasut wrote:
> [CAUTION: This email is from outside your organization. Unless you trust 
> the sender, do not click on links or open attachments as it may be a 
> fraudulent email attempting to steal your information and/or compromise 
> your computer.]
> 
> On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> 
> Hello everyone,
> 
>> I already have the referenced commit in my test branch, and I can
>> confirm that the same compilation error still appears on CycloneV when
>> certain directories produce no SPL objects.
>>
>> The existing fix ensures that built-in.o is always present, but it does
>> not prevent ar from generating empty built-in.a archives, which older
>> ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
>> truncated”.
> 
> Which toolchain is this ?
> 

I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 
devices - CycloneV and Arria10

>> This patch complements the earlier fix by ensuring that each SPL
>> directory contributes at least one real object, so the resulting built-
>> in.a archives are non-empty and accepted by all toolchains. It does not
>> change runtime behavior—only ensures the archives remain valid.
>>
>> Thanks,
>> Alif
>>
> 
> 
> -- 
> Best regards,
> Marek Vasut

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> 
> 
> On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > [CAUTION: This email is from outside your organization. Unless you trust
> > the sender, do not click on links or open attachments as it may be a
> > fraudulent email attempting to steal your information and/or compromise
> > your computer.]
> > 
> > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > 
> > Hello everyone,
> > 
> > > I already have the referenced commit in my test branch, and I can
> > > confirm that the same compilation error still appears on CycloneV when
> > > certain directories produce no SPL objects.
> > > 
> > > The existing fix ensures that built-in.o is always present, but it does
> > > not prevent ar from generating empty built-in.a archives, which older
> > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > truncated”.
> > 
> > Which toolchain is this ?
> > 
> 
> I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> - CycloneV and Arria10

Ilias, do you recall the solution to this problem from when it came up
on IRC a few weeks ago?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Hi Tom,

Tom Rini <trini@konsulko.com> 於 2025年11月28日週五 下午11:31寫道：
>
> On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> >
> >
> > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > [CAUTION: This email is from outside your organization. Unless you trust
> > > the sender, do not click on links or open attachments as it may be a
> > > fraudulent email attempting to steal your information and/or compromise
> > > your computer.]
> > >
> > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > >
> > > Hello everyone,
> > >
> > > > I already have the referenced commit in my test branch, and I can
> > > > confirm that the same compilation error still appears on CycloneV when
> > > > certain directories produce no SPL objects.
> > > >
> > > > The existing fix ensures that built-in.o is always present, but it does
> > > > not prevent ar from generating empty built-in.a archives, which older
> > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > truncated”.

I encountered this mid of this year after 2025.07.
The uncompilable distro is Ubuntu 18.04, however once I update
to 20.0x and 22.xx there are no issue anymore.

But I did not deep investigate this issue because distro updated can
resolve this issue. I simply think it is u-boot no longer support old GCC.
Just want to point out the failing point of my experiences.

Thanks,
Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Ilias Apalodimas]

On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> >
> >
> > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > [CAUTION: This email is from outside your organization. Unless you trust
> > > the sender, do not click on links or open attachments as it may be a
> > > fraudulent email attempting to steal your information and/or compromise
> > > your computer.]
> > >
> > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > >
> > > Hello everyone,
> > >
> > > > I already have the referenced commit in my test branch, and I can
> > > > confirm that the same compilation error still appears on CycloneV when
> > > > certain directories produce no SPL objects.
> > > >
> > > > The existing fix ensures that built-in.o is always present, but it does
> > > > not prevent ar from generating empty built-in.a archives, which older
> > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > truncated”.
> > >
> > > Which toolchain is this ?
> > >
> >
> > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > - CycloneV and Arria10
>
> Ilias, do you recall the solution to this problem from when it came up
> on IRC a few weeks ago?

Nop unfortunately not.
Was this caused by the Kbuild bump? I remember the logic around
builtin changing significantly.

Cheers
/Ilias
>
> --
> Tom

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > >
> > >
> > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > the sender, do not click on links or open attachments as it may be a
> > > > fraudulent email attempting to steal your information and/or compromise
> > > > your computer.]
> > > >
> > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > > I already have the referenced commit in my test branch, and I can
> > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > certain directories produce no SPL objects.
> > > > >
> > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > truncated”.
> > > >
> > > > Which toolchain is this ?
> > > >
> > >
> > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > - CycloneV and Arria10
> >
> > Ilias, do you recall the solution to this problem from when it came up
> > on IRC a few weeks ago?
> 
> Nop unfortunately not.
> Was this caused by the Kbuild bump? I remember the logic around
> builtin changing significantly.

Yes, and I kinda thought we narrowed it down to something being missing
from the update, since the kernel does support this old of a toolchain
(or at least the 10.x? someone else this on).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
>
> On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > >
> > > >
> > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > the sender, do not click on links or open attachments as it may be a
> > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > your computer.]
> > > > >
> > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > >
> > > > > Hello everyone,
> > > > >
> > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > certain directories produce no SPL objects.
> > > > > >
> > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > truncated”.
> > > > >
> > > > > Which toolchain is this ?
> > > > >
> > > >
> > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > - CycloneV and Arria10
> > >
> > > Ilias, do you recall the solution to this problem from when it came up
> > > on IRC a few weeks ago?
> >
> > Nop unfortunately not.
> > Was this caused by the Kbuild bump? I remember the logic around
> > builtin changing significantly.
>
> Yes, and I kinda thought we narrowed it down to something being missing
> from the update, since the kernel does support this old of a toolchain
> (or at least the 10.x? someone else this on).

Hi Tom,

Actually I am not sure u-boot itself have minimum requirement on each tag
or branch listed?

On ubuntu 18.04 LTS

HEAD detached at v2025.10

x-gnueabi-ld.real: arch/arm/cpu/built-in.a: file not recognized: file truncated
scripts/Makefile.xpl:541: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 1
Makefile:2358: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error 2

Same fail I experienced before.
All are default distro package
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
arm-xilinx-linux-gnueabi-gcc.real (GCC) 9.2.0

On Ubuntu 22.04 LTS

No issue on build what so ever.
All are default distro package
gcc (Ubuntu 11.4.0-1ubuntu1~22.04.2) 11.4.
arm-linux-gnueabihf-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

Thanks,
Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]

On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> >
> > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > >
> > > > >
> > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > your computer.]
> > > > > >
> > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > >
> > > > > > Hello everyone,
> > > > > >
> > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > certain directories produce no SPL objects.
> > > > > > >
> > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > truncated”.
> > > > > >
> > > > > > Which toolchain is this ?
> > > > > >
> > > > >
> > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > - CycloneV and Arria10
> > > >
> > > > Ilias, do you recall the solution to this problem from when it came up
> > > > on IRC a few weeks ago?
> > >
> > > Nop unfortunately not.
> > > Was this caused by the Kbuild bump? I remember the logic around
> > > builtin changing significantly.
> >
> > Yes, and I kinda thought we narrowed it down to something being missing
> > from the update, since the kernel does support this old of a toolchain
> > (or at least the 10.x? someone else this on).
> 
> Hi Tom,
> 
> Actually I am not sure u-boot itself have minimum requirement on each tag
> or branch listed?

We do not currently have a test for anything other than "newer than
gcc-6" for ARM, but should have the same minimum requirements as the
linux kernel, but are lacking enforcement checks (but I also think the
kernel is?).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
>
> On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > >
> > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > >
> > > > > >
> > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > your computer.]
> > > > > > >
> > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > >
> > > > > > > Hello everyone,
> > > > > > >
> > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > certain directories produce no SPL objects.
> > > > > > > >
> > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > truncated”.
> > > > > > >
> > > > > > > Which toolchain is this ?
> > > > > > >
> > > > > >
> > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > - CycloneV and Arria10
> > > > >
> > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > on IRC a few weeks ago?
> > > >
> > > > Nop unfortunately not.
> > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > builtin changing significantly.
> > >
> > > Yes, and I kinda thought we narrowed it down to something being missing
> > > from the update, since the kernel does support this old of a toolchain
> > > (or at least the 10.x? someone else this on).
> >
> > Hi Tom,
> >
> > Actually I am not sure u-boot itself have minimum requirement on each tag
> > or branch listed?
>
> We do not currently have a test for anything other than "newer than
> gcc-6" for ARM, but should have the same minimum requirements as the
> linux kernel, but are lacking enforcement checks (but I also think the
> kernel is?).
>
> --
> Tom

Hi Tom,

Oops, missing the kernel version. Add it back for better debug.

For Ubuntu 18.04
Default used old 5.4.0-150-generic

For Ubuntu 22.04
Default used 5.15.0-161-generic

So working kernel not even up to kernel 6.

But do that issue actually caused by GCC version or not?
When gcc-6 should able to build properly.

And do gcc-6 means kernel or the gcc version itself.

Thanks,
Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3139 bytes --]

On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> >
> > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > >
> > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > your computer.]
> > > > > > > >
> > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > >
> > > > > > > > Hello everyone,
> > > > > > > >
> > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > >
> > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > truncated”.
> > > > > > > >
> > > > > > > > Which toolchain is this ?
> > > > > > > >
> > > > > > >
> > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > - CycloneV and Arria10
> > > > > >
> > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > on IRC a few weeks ago?
> > > > >
> > > > > Nop unfortunately not.
> > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > builtin changing significantly.
> > > >
> > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > from the update, since the kernel does support this old of a toolchain
> > > > (or at least the 10.x? someone else this on).
> > >
> > > Hi Tom,
> > >
> > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > or branch listed?
> >
> > We do not currently have a test for anything other than "newer than
> > gcc-6" for ARM, but should have the same minimum requirements as the
> > linux kernel, but are lacking enforcement checks (but I also think the
> > kernel is?).
> >
> > --
> > Tom
> 
> Hi Tom,
> 
> Oops, missing the kernel version. Add it back for better debug.

Sorry, what I meant was that it's a kbuild related issue as to what
version of gcc can be used. We don't have a check, and should, but also
the versions in question here should be expected to work. There's just
some change we're missing.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
>
> On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > >
> > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > >
> > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > your computer.]
> > > > > > > > >
> > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > >
> > > > > > > > > Hello everyone,
> > > > > > > > >
> > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > >
> > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > truncated”.
> > > > > > > > >
> > > > > > > > > Which toolchain is this ?
> > > > > > > > >
> > > > > > > >
> > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > - CycloneV and Arria10
> > > > > > >
> > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > on IRC a few weeks ago?
> > > > > >
> > > > > > Nop unfortunately not.
> > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > builtin changing significantly.
> > > > >
> > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > from the update, since the kernel does support this old of a toolchain
> > > > > (or at least the 10.x? someone else this on).
> > > >
> > > > Hi Tom,
> > > >
> > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > or branch listed?
> > >
> > > We do not currently have a test for anything other than "newer than
> > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > linux kernel, but are lacking enforcement checks (but I also think the
> > > kernel is?).
> > >
> > > --
> > > Tom
> >
> > Hi Tom,
> >
> > Oops, missing the kernel version. Add it back for better debug.
>
> Sorry, what I meant was that it's a kbuild related issue as to what
> version of gcc can be used. We don't have a check, and should, but also
> the versions in question here should be expected to work. There's just
> some change we're missing.
>
> --
> Tom

So long story short this patch itself should not introduce from beginning.
It is a GCC version depended issue.
But how to pin-point down to which version is a bit hard.
Distro link with GCC version and not all gcc version can easily checked.

Any idea how to easily check this?

Thanks,
Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]

On Tue, Dec 02, 2025 at 01:07:00AM +0800, Sune Brian wrote:
> Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
> >
> > On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > > >
> > > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > > >
> > > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > > your computer.]
> > > > > > > > > >
> > > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > >
> > > > > > > > > > Hello everyone,
> > > > > > > > > >
> > > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > > >
> > > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > > truncated”.
> > > > > > > > > >
> > > > > > > > > > Which toolchain is this ?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > > - CycloneV and Arria10
> > > > > > > >
> > > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > > on IRC a few weeks ago?
> > > > > > >
> > > > > > > Nop unfortunately not.
> > > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > > builtin changing significantly.
> > > > > >
> > > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > > from the update, since the kernel does support this old of a toolchain
> > > > > > (or at least the 10.x? someone else this on).
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > > or branch listed?
> > > >
> > > > We do not currently have a test for anything other than "newer than
> > > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > > linux kernel, but are lacking enforcement checks (but I also think the
> > > > kernel is?).
> > > >
> > > > --
> > > > Tom
> > >
> > > Hi Tom,
> > >
> > > Oops, missing the kernel version. Add it back for better debug.
> >
> > Sorry, what I meant was that it's a kbuild related issue as to what
> > version of gcc can be used. We don't have a check, and should, but also
> > the versions in question here should be expected to work. There's just
> > some change we're missing.
> >
> > --
> > Tom
> 
> So long story short this patch itself should not introduce from beginning.
> It is a GCC version depended issue.
> But how to pin-point down to which version is a bit hard.
> Distro link with GCC version and not all gcc version can easily checked.
> 
> Any idea how to easily check this?

We can use the check we have today in arch/arm/config.mk under
"checkgcc6" to check for something much newer. But! It's a problem of a
missing kbuild change I think, based on when this problem was first
reported.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午1:09寫道：

>
> On Tue, Dec 02, 2025 at 01:07:00AM +0800, Sune Brian wrote:
> > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
> > >
> > > On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > > > >
> > > > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > > > >
> > > > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > > > your computer.]
> > > > > > > > > > >
> > > > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hello everyone,
> > > > > > > > > > >
> > > > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > > > >
> > > > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > > > truncated”.
> > > > > > > > > > >
> > > > > > > > > > > Which toolchain is this ?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > > > - CycloneV and Arria10
> > > > > > > > >
> > > > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > > > on IRC a few weeks ago?
> > > > > > > >
> > > > > > > > Nop unfortunately not.
> > > > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > > > builtin changing significantly.
> > > > > > >
> > > > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > > > from the update, since the kernel does support this old of a toolchain
> > > > > > > (or at least the 10.x? someone else this on).
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > > > or branch listed?
> > > > >
> > > > > We do not currently have a test for anything other than "newer than
> > > > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > > > linux kernel, but are lacking enforcement checks (but I also think the
> > > > > kernel is?).
> > > > >
> > > > > --
> > > > > Tom
> > > >
> > > > Hi Tom,
> > > >
> > > > Oops, missing the kernel version. Add it back for better debug.
> > >
> > > Sorry, what I meant was that it's a kbuild related issue as to what
> > > version of gcc can be used. We don't have a check, and should, but also
> > > the versions in question here should be expected to work. There's just
> > > some change we're missing.
> > >
> > > --
> > > Tom
> >
> > So long story short this patch itself should not introduce from beginning.
> > It is a GCC version depended issue.
> > But how to pin-point down to which version is a bit hard.
> > Distro link with GCC version and not all gcc version can easily checked.
> >
> > Any idea how to easily check this?
>
> We can use the check we have today in arch/arm/config.mk under
> "checkgcc6" to check for something much newer. But! It's a problem of a
> missing kbuild change I think, based on when this problem was first
> reported.
>
> --
> Tom

Tom,

For GCC version sub-version do not matters?
For example 6.x.x 7.x.x 8.x.x
Or 9.3 9.4 etc also matters?
So to determine the supported version it just need to pin-point to
the major GCC version?
Then the possible version break only <=10 or <10?
Based on the previous build success case.
9.2.0 fails 11.4.0 passed.

Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5313 bytes --]

On Tue, Dec 02, 2025 at 01:59:53AM +0800, Sune Brian wrote:
> Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午1:09寫道：
> 
> >
> > On Tue, Dec 02, 2025 at 01:07:00AM +0800, Sune Brian wrote:
> > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
> > > >
> > > > On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > > > > >
> > > > > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > > > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > > > > >
> > > > > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > > > > your computer.]
> > > > > > > > > > > >
> > > > > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > >
> > > > > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > > > > truncated”.
> > > > > > > > > > > >
> > > > > > > > > > > > Which toolchain is this ?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > > > > - CycloneV and Arria10
> > > > > > > > > >
> > > > > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > > > > on IRC a few weeks ago?
> > > > > > > > >
> > > > > > > > > Nop unfortunately not.
> > > > > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > > > > builtin changing significantly.
> > > > > > > >
> > > > > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > > > > from the update, since the kernel does support this old of a toolchain
> > > > > > > > (or at least the 10.x? someone else this on).
> > > > > > >
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > > > > or branch listed?
> > > > > >
> > > > > > We do not currently have a test for anything other than "newer than
> > > > > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > > > > linux kernel, but are lacking enforcement checks (but I also think the
> > > > > > kernel is?).
> > > > > >
> > > > > > --
> > > > > > Tom
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > Oops, missing the kernel version. Add it back for better debug.
> > > >
> > > > Sorry, what I meant was that it's a kbuild related issue as to what
> > > > version of gcc can be used. We don't have a check, and should, but also
> > > > the versions in question here should be expected to work. There's just
> > > > some change we're missing.
> > > >
> > > > --
> > > > Tom
> > >
> > > So long story short this patch itself should not introduce from beginning.
> > > It is a GCC version depended issue.
> > > But how to pin-point down to which version is a bit hard.
> > > Distro link with GCC version and not all gcc version can easily checked.
> > >
> > > Any idea how to easily check this?
> >
> > We can use the check we have today in arch/arm/config.mk under
> > "checkgcc6" to check for something much newer. But! It's a problem of a
> > missing kbuild change I think, based on when this problem was first
> > reported.
> >
> > --
> > Tom
> 
> Tom,
> 
> For GCC version sub-version do not matters?
> For example 6.x.x 7.x.x 8.x.x
> Or 9.3 9.4 etc also matters?
> So to determine the supported version it just need to pin-point to
> the major GCC version?
> Then the possible version break only <=10 or <10?
> Based on the previous build success case.
> 9.2.0 fails 11.4.0 passed.

Looking through logs now, I see the kernel says 8.1 or newer:
https://www.kernel.org/doc/html/latest/process/changes.html which is why
I have been saying there's an underlying kbuild problem (missing
change(s)) that needs to be resolved. I don't know if 10.x works or
fails, but that's still beside the point to me as 9.2.0 should work.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午2:27寫道：
>
> On Tue, Dec 02, 2025 at 01:59:53AM +0800, Sune Brian wrote:
> > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午1:09寫道：
> >
> > >
> > > On Tue, Dec 02, 2025 at 01:07:00AM +0800, Sune Brian wrote:
> > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
> > > > >
> > > > > On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > > > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > > > > > >
> > > > > > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > > > > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > > > > > >
> > > > > > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > > > > > your computer.]
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > > > > > truncated”.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Which toolchain is this ?
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > > > > > - CycloneV and Arria10
> > > > > > > > > > >
> > > > > > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > > > > > on IRC a few weeks ago?
> > > > > > > > > >
> > > > > > > > > > Nop unfortunately not.
> > > > > > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > > > > > builtin changing significantly.
> > > > > > > > >
> > > > > > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > > > > > from the update, since the kernel does support this old of a toolchain
> > > > > > > > > (or at least the 10.x? someone else this on).
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > > > > > or branch listed?
> > > > > > >
> > > > > > > We do not currently have a test for anything other than "newer than
> > > > > > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > > > > > linux kernel, but are lacking enforcement checks (but I also think the
> > > > > > > kernel is?).
> > > > > > >
> > > > > > > --
> > > > > > > Tom
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > Oops, missing the kernel version. Add it back for better debug.
> > > > >
> > > > > Sorry, what I meant was that it's a kbuild related issue as to what
> > > > > version of gcc can be used. We don't have a check, and should, but also
> > > > > the versions in question here should be expected to work. There's just
> > > > > some change we're missing.
> > > > >
> > > > > --
> > > > > Tom
> > > >
> > > > So long story short this patch itself should not introduce from beginning.
> > > > It is a GCC version depended issue.
> > > > But how to pin-point down to which version is a bit hard.
> > > > Distro link with GCC version and not all gcc version can easily checked.
> > > >
> > > > Any idea how to easily check this?
> > >
> > > We can use the check we have today in arch/arm/config.mk under
> > > "checkgcc6" to check for something much newer. But! It's a problem of a
> > > missing kbuild change I think, based on when this problem was first
> > > reported.
> > >
> > > --
> > > Tom
> >
> > Tom,
> >
> > For GCC version sub-version do not matters?
> > For example 6.x.x 7.x.x 8.x.x
> > Or 9.3 9.4 etc also matters?
> > So to determine the supported version it just need to pin-point to
> > the major GCC version?
> > Then the possible version break only <=10 or <10?
> > Based on the previous build success case.
> > 9.2.0 fails 11.4.0 passed.
>
> Looking through logs now, I see the kernel says 8.1 or newer:
> https://www.kernel.org/doc/html/latest/process/changes.html which is why
> I have been saying there's an underlying kbuild problem (missing
> change(s)) that needs to be resolved. I don't know if 10.x works or
> fails, but that's still beside the point to me as 9.2.0 should work.
>
> --
> Tom

Do this apply to arm-linux-gnueabihf-gcc ?
Or the 8.1 is apply to base gcc not cross-compile?
Just want to confirm.

Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6118 bytes --]

On Tue, Dec 02, 2025 at 02:37:42AM +0800, Sune Brian wrote:
> Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午2:27寫道：
> >
> > On Tue, Dec 02, 2025 at 01:59:53AM +0800, Sune Brian wrote:
> > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午1:09寫道：
> > >
> > > >
> > > > On Tue, Dec 02, 2025 at 01:07:00AM +0800, Sune Brian wrote:
> > > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
> > > > > >
> > > > > > On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > > > > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > > > > > > >
> > > > > > > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > > > > > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > > > > > > >
> > > > > > > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > > > > > > your computer.]
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > > > > > > truncated”.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Which toolchain is this ?
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > > > > > > - CycloneV and Arria10
> > > > > > > > > > > >
> > > > > > > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > > > > > > on IRC a few weeks ago?
> > > > > > > > > > >
> > > > > > > > > > > Nop unfortunately not.
> > > > > > > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > > > > > > builtin changing significantly.
> > > > > > > > > >
> > > > > > > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > > > > > > from the update, since the kernel does support this old of a toolchain
> > > > > > > > > > (or at least the 10.x? someone else this on).
> > > > > > > > >
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > > > > > > or branch listed?
> > > > > > > >
> > > > > > > > We do not currently have a test for anything other than "newer than
> > > > > > > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > > > > > > linux kernel, but are lacking enforcement checks (but I also think the
> > > > > > > > kernel is?).
> > > > > > > >
> > > > > > > > --
> > > > > > > > Tom
> > > > > > >
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > Oops, missing the kernel version. Add it back for better debug.
> > > > > >
> > > > > > Sorry, what I meant was that it's a kbuild related issue as to what
> > > > > > version of gcc can be used. We don't have a check, and should, but also
> > > > > > the versions in question here should be expected to work. There's just
> > > > > > some change we're missing.
> > > > > >
> > > > > > --
> > > > > > Tom
> > > > >
> > > > > So long story short this patch itself should not introduce from beginning.
> > > > > It is a GCC version depended issue.
> > > > > But how to pin-point down to which version is a bit hard.
> > > > > Distro link with GCC version and not all gcc version can easily checked.
> > > > >
> > > > > Any idea how to easily check this?
> > > >
> > > > We can use the check we have today in arch/arm/config.mk under
> > > > "checkgcc6" to check for something much newer. But! It's a problem of a
> > > > missing kbuild change I think, based on when this problem was first
> > > > reported.
> > > >
> > > > --
> > > > Tom
> > >
> > > Tom,
> > >
> > > For GCC version sub-version do not matters?
> > > For example 6.x.x 7.x.x 8.x.x
> > > Or 9.3 9.4 etc also matters?
> > > So to determine the supported version it just need to pin-point to
> > > the major GCC version?
> > > Then the possible version break only <=10 or <10?
> > > Based on the previous build success case.
> > > 9.2.0 fails 11.4.0 passed.
> >
> > Looking through logs now, I see the kernel says 8.1 or newer:
> > https://www.kernel.org/doc/html/latest/process/changes.html which is why
> > I have been saying there's an underlying kbuild problem (missing
> > change(s)) that needs to be resolved. I don't know if 10.x works or
> > fails, but that's still beside the point to me as 9.2.0 should work.
> >
> > --
> > Tom
> 
> Do this apply to arm-linux-gnueabihf-gcc ?
> Or the 8.1 is apply to base gcc not cross-compile?
> Just want to confirm.

Yes, it's gcc 8.1 regardless of if it's a cross compiler or not.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午2:38寫道：
>
> On Tue, Dec 02, 2025 at 02:37:42AM +0800, Sune Brian wrote:
> > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午2:27寫道：
> > >
> > > On Tue, Dec 02, 2025 at 01:59:53AM +0800, Sune Brian wrote:
> > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午1:09寫道：
> > > >
> > > > >
> > > > > On Tue, Dec 02, 2025 at 01:07:00AM +0800, Sune Brian wrote:
> > > > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
> > > > > > >
> > > > > > > On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > > > > > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > > > > > > > >
> > > > > > > > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > > > > > > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > > > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > > > > > > > your computer.]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > > > > > > > truncated”.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Which toolchain is this ?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > > > > > > > - CycloneV and Arria10
> > > > > > > > > > > > >
> > > > > > > > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > > > > > > > on IRC a few weeks ago?
> > > > > > > > > > > >
> > > > > > > > > > > > Nop unfortunately not.
> > > > > > > > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > > > > > > > builtin changing significantly.
> > > > > > > > > > >
> > > > > > > > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > > > > > > > from the update, since the kernel does support this old of a toolchain
> > > > > > > > > > > (or at least the 10.x? someone else this on).
> > > > > > > > > >
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > > > > > > > or branch listed?
> > > > > > > > >
> > > > > > > > > We do not currently have a test for anything other than "newer than
> > > > > > > > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > > > > > > > linux kernel, but are lacking enforcement checks (but I also think the
> > > > > > > > > kernel is?).
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Tom
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > Oops, missing the kernel version. Add it back for better debug.
> > > > > > >
> > > > > > > Sorry, what I meant was that it's a kbuild related issue as to what
> > > > > > > version of gcc can be used. We don't have a check, and should, but also
> > > > > > > the versions in question here should be expected to work. There's just
> > > > > > > some change we're missing.
> > > > > > >
> > > > > > > --
> > > > > > > Tom
> > > > > >
> > > > > > So long story short this patch itself should not introduce from beginning.
> > > > > > It is a GCC version depended issue.
> > > > > > But how to pin-point down to which version is a bit hard.
> > > > > > Distro link with GCC version and not all gcc version can easily checked.
> > > > > >
> > > > > > Any idea how to easily check this?
> > > > >
> > > > > We can use the check we have today in arch/arm/config.mk under
> > > > > "checkgcc6" to check for something much newer. But! It's a problem of a
> > > > > missing kbuild change I think, based on when this problem was first
> > > > > reported.
> > > > >
> > > > > --
> > > > > Tom
> > > >
> > > > Tom,
> > > >
> > > > For GCC version sub-version do not matters?
> > > > For example 6.x.x 7.x.x 8.x.x
> > > > Or 9.3 9.4 etc also matters?
> > > > So to determine the supported version it just need to pin-point to
> > > > the major GCC version?
> > > > Then the possible version break only <=10 or <10?
> > > > Based on the previous build success case.
> > > > 9.2.0 fails 11.4.0 passed.
> > >
> > > Looking through logs now, I see the kernel says 8.1 or newer:
> > > https://www.kernel.org/doc/html/latest/process/changes.html which is why
> > > I have been saying there's an underlying kbuild problem (missing
> > > change(s)) that needs to be resolved. I don't know if 10.x works or
> > > fails, but that's still beside the point to me as 9.2.0 should work.
> > >
> > > --
> > > Tom
> >
> > Do this apply to arm-linux-gnueabihf-gcc ?
> > Or the 8.1 is apply to base gcc not cross-compile?
> > Just want to confirm.
>
> Yes, it's gcc 8.1 regardless of if it's a cross compiler or not.
>
> --
> Tom

I guess simply use local prebuild test is fastest [1].
But this is still interesting that two VM also used 18.04 failed before.
So I just do a simply test.

arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture
8.2-2018-08 (arm-rel-8.23)) 8.2.1 20180802
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

arch/arm/cpu/built-in.a: file not recognized: File truncated
scripts/Makefile.xpl:542: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 1
Makefile:2358: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error 2

Brian

[1] https://developer.arm.com/downloads/-/gnu-a

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午2:38寫道：
>
> On Tue, Dec 02, 2025 at 02:37:42AM +0800, Sune Brian wrote:
> > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午2:27寫道：
> > >
> > > On Tue, Dec 02, 2025 at 01:59:53AM +0800, Sune Brian wrote:
> > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午1:09寫道：
> > > >
> > > > >
> > > > > On Tue, Dec 02, 2025 at 01:07:00AM +0800, Sune Brian wrote:
> > > > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:54寫道：
> > > > > > >
> > > > > > > On Tue, Dec 02, 2025 at 12:52:06AM +0800, Sune Brian wrote:
> > > > > > > > Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午12:44寫道：
> > > > > > > > >
> > > > > > > > > On Sat, Nov 29, 2025 at 08:46:14AM +0800, Sune Brian wrote:
> > > > > > > > > > Tom Rini <trini@konsulko.com> 於 2025年11月29日週六 上午12:50寫道：
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > > > > > > > > > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > > > > > > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > > > > > > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > > > > > > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > > > > > > > > > > your computer.]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hello everyone,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > > > > > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > > > > > > > > > > certain directories produce no SPL objects.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > > > > > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > > > > > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > > > > > > > > > > truncated”.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Which toolchain is this ?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > > > > > > > > > > - CycloneV and Arria10
> > > > > > > > > > > > >
> > > > > > > > > > > > > Ilias, do you recall the solution to this problem from when it came up
> > > > > > > > > > > > > on IRC a few weeks ago?
> > > > > > > > > > > >
> > > > > > > > > > > > Nop unfortunately not.
> > > > > > > > > > > > Was this caused by the Kbuild bump? I remember the logic around
> > > > > > > > > > > > builtin changing significantly.
> > > > > > > > > > >
> > > > > > > > > > > Yes, and I kinda thought we narrowed it down to something being missing
> > > > > > > > > > > from the update, since the kernel does support this old of a toolchain
> > > > > > > > > > > (or at least the 10.x? someone else this on).
> > > > > > > > > >
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > Actually I am not sure u-boot itself have minimum requirement on each tag
> > > > > > > > > > or branch listed?
> > > > > > > > >
> > > > > > > > > We do not currently have a test for anything other than "newer than
> > > > > > > > > gcc-6" for ARM, but should have the same minimum requirements as the
> > > > > > > > > linux kernel, but are lacking enforcement checks (but I also think the
> > > > > > > > > kernel is?).
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Tom
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > Oops, missing the kernel version. Add it back for better debug.
> > > > > > >
> > > > > > > Sorry, what I meant was that it's a kbuild related issue as to what
> > > > > > > version of gcc can be used. We don't have a check, and should, but also
> > > > > > > the versions in question here should be expected to work. There's just
> > > > > > > some change we're missing.
> > > > > > >
> > > > > > > --
> > > > > > > Tom
> > > > > >
> > > > > > So long story short this patch itself should not introduce from beginning.
> > > > > > It is a GCC version depended issue.
> > > > > > But how to pin-point down to which version is a bit hard.
> > > > > > Distro link with GCC version and not all gcc version can easily checked.
> > > > > >
> > > > > > Any idea how to easily check this?
> > > > >
> > > > > We can use the check we have today in arch/arm/config.mk under
> > > > > "checkgcc6" to check for something much newer. But! It's a problem of a
> > > > > missing kbuild change I think, based on when this problem was first
> > > > > reported.
> > > > >
> > > > > --
> > > > > Tom
> > > >
> > > > Tom,
> > > >
> > > > For GCC version sub-version do not matters?
> > > > For example 6.x.x 7.x.x 8.x.x
> > > > Or 9.3 9.4 etc also matters?
> > > > So to determine the supported version it just need to pin-point to
> > > > the major GCC version?
> > > > Then the possible version break only <=10 or <10?
> > > > Based on the previous build success case.
> > > > 9.2.0 fails 11.4.0 passed.
> > >
> > > Looking through logs now, I see the kernel says 8.1 or newer:
> > > https://www.kernel.org/doc/html/latest/process/changes.html which is why
> > > I have been saying there's an underlying kbuild problem (missing
> > > change(s)) that needs to be resolved. I don't know if 10.x works or
> > > fails, but that's still beside the point to me as 9.2.0 should work.
> > >
> > > --
> > > Tom
> >
> > Do this apply to arm-linux-gnueabihf-gcc ?
> > Or the 8.1 is apply to base gcc not cross-compile?
> > Just want to confirm.
>
> Yes, it's gcc 8.1 regardless of if it's a cross compiler or not.
>
> --
> Tom

Long story short:

arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile
Architecture 10.2-2020.11 (arm-10.16)) 10.2.1 20201103
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  SYM     spl/u-boot-spl.sym
  CAT     spl/u-boot-spl-dtb.bin
  COPY    spl/u-boot-spl.bin
  MKIMAGE spl/u-boot-spl.sfp
  GENSPLX4 spl/u-boot-splx4.sfp
  SOCBOOT u-boot-with-spl.sfp
  OFCHK   .config

arm-linux-gnueabihf-gcc (Ubuntu 10-20200411-0ubuntu1) 10.0.1 20200411
(experimental) [master revision
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566]
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  LD      spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  SYM     spl/u-boot-spl.sym
  CAT     spl/u-boot-spl-dtb.bin
  COPY    spl/u-boot-spl.bin
  MKIMAGE spl/u-boot-spl.sfp
  GENSPLX4 spl/u-boot-splx4.sfp
  SOCBOOT u-boot-with-spl.sfp
  OFCHK   .config

arm-none-linux-gnueabihf-ld: arch/arm/cpu/built-in.a: file not
recognized: file truncated
scripts/Makefile.xpl:542: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 1
Makefile:2358: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error 2

arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile
Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

So 10.0.1 should be good enough.

Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Ilias Apalodimas]

Hi Tom,

On Fri, 28 Nov 2025 at 18:50, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > >
> > > >
> > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > the sender, do not click on links or open attachments as it may be a
> > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > your computer.]
> > > > >
> > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > >
> > > > > Hello everyone,
> > > > >
> > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > certain directories produce no SPL objects.
> > > > > >
> > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > truncated”.
> > > > >
> > > > > Which toolchain is this ?
> > > > >
> > > >
> > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > - CycloneV and Arria10
> > >
> > > Ilias, do you recall the solution to this problem from when it came up
> > > on IRC a few weeks ago?
> >
> > Nop unfortunately not.
> > Was this caused by the Kbuild bump? I remember the logic around
> > builtin changing significantly.
>
> Yes, and I kinda thought we narrowed it down to something being missing
> from the update, since the kernel does support this old of a toolchain
> (or at least the 10.x? someone else this on).

Ok, let me go through my irc logs in case I find it.
Reading the email thread we should compile with anything > 8.1 right?

Cheers
/Ilias
>
> --
> Tom

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Ilias Apalodimas <ilias.apalodimas@linaro.org> 於 2025年12月2日週二 下午3:56寫道：
>
> Hi Tom,
>
> On Fri, 28 Nov 2025 at 18:50, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Nov 28, 2025 at 06:44:12PM +0200, Ilias Apalodimas wrote:
> > > On Fri, 28 Nov 2025 at 17:31, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Fri, Nov 28, 2025 at 10:11:53AM +0800, Yuslaimi, Alif Zakuan wrote:
> > > > >
> > > > >
> > > > > On 27/11/2025 11:09 pm, Marek Vasut wrote:
> > > > > > [CAUTION: This email is from outside your organization. Unless you trust
> > > > > > the sender, do not click on links or open attachments as it may be a
> > > > > > fraudulent email attempting to steal your information and/or compromise
> > > > > > your computer.]
> > > > > >
> > > > > > On 11/27/25 3:12 AM, Yuslaimi, Alif Zakuan wrote:
> > > > > >
> > > > > > Hello everyone,
> > > > > >
> > > > > > > I already have the referenced commit in my test branch, and I can
> > > > > > > confirm that the same compilation error still appears on CycloneV when
> > > > > > > certain directories produce no SPL objects.
> > > > > > >
> > > > > > > The existing fix ensures that built-in.o is always present, but it does
> > > > > > > not prevent ar from generating empty built-in.a archives, which older
> > > > > > > ARM 32-bit linkers (such as CycloneV toolchains) reject as “file
> > > > > > > truncated”.
> > > > > >
> > > > > > Which toolchain is this ?
> > > > > >
> > > > >
> > > > > I am using Linaro arm-linux-gnueabihf GCC 7.5.0 to compile our SoC32 devices
> > > > > - CycloneV and Arria10
> > > >
> > > > Ilias, do you recall the solution to this problem from when it came up
> > > > on IRC a few weeks ago?
> > >
> > > Nop unfortunately not.
> > > Was this caused by the Kbuild bump? I remember the logic around
> > > builtin changing significantly.
> >
> > Yes, and I kinda thought we narrowed it down to something being missing
> > from the update, since the kernel does support this old of a toolchain
> > (or at least the 10.x? someone else this on).
>
> Ok, let me go through my irc logs in case I find it.
> Reading the email thread we should compile with anything > 8.1 right?
>
> Cheers
> /Ilias
> >
> > --
> > Tom

Hi llias and Tom,

I have a question might be wrong or not even exist.
Tom mentioned GCC 8.1 kbuild but u-boot is considered as
kernel build or it does not always be that case?

At least so fat there are nothing can build properly below 10.0.1
Using ARM official cross compile binaries.

Thanks,
Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Ilias Apalodimas]

[...]

> >
> > Ok, let me go through my irc logs in case I find it.
> > Reading the email thread we should compile with anything > 8.1 right?
> >
> > Cheers
> > /Ilias
> > >
> > > --
> > > Tom
>
> Hi llias and Tom,
>
> I have a question might be wrong or not even exist.
> Tom mentioned GCC 8.1 kbuild but u-boot is considered as
> kernel build or it does not always be that case?

We use the same Kbuild system as the kernel. I updated that a few
months ago since we where stuck on a really old version.

>
> At least so fat there are nothing can build properly below 10.0.1
> Using ARM official cross compile binaries.

I think I tested with gcc11, but I I don't remember testing with 8.x.
I probably missed something on the backporting. I'll try having a look

Cheers
/Ilias
>
> Thanks,
> Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Ilias Apalodimas <ilias.apalodimas@linaro.org> 於 2025年12月2日週二 下午4:53寫道：
>
> [...]
>
> > >
> > > Ok, let me go through my irc logs in case I find it.
> > > Reading the email thread we should compile with anything > 8.1 right?
> > >
> > > Cheers
> > > /Ilias
> > > >
> > > > --
> > > > Tom
> >
> > Hi llias and Tom,
> >
> > I have a question might be wrong or not even exist.
> > Tom mentioned GCC 8.1 kbuild but u-boot is considered as
> > kernel build or it does not always be that case?
>
> We use the same Kbuild system as the kernel. I updated that a few
> months ago since we where stuck on a really old version.
>
> >
> > At least so fat there are nothing can build properly below 10.0.1
> > Using ARM official cross compile binaries.
>
> I think I tested with gcc11, but I I don't remember testing with 8.x.
> I probably missed something on the backporting. I'll try having a look
>
> Cheers
> /Ilias
> >
> > Thanks,
> > Brian

Thank you IIias I don't really know all the u-boot things.
I had provided the first draft for fixing GCC check.
https://patchwork.ozlabs.org/project/uboot/patch/20251202041029.186-1-briansune@gmail.com/
Now it is on 10.0.1 if 8.1 is the case will update after your confirmation.

Thanks,
Brian

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Yuslaimi, Alif Zakuan]

Hi,

On 2/12/2025 4:59 pm, Sune Brian wrote:
> [CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
> 
> Ilias Apalodimas <ilias.apalodimas@linaro.org> 於 2025年12月2日週二 下午4:53寫道：
>>
>> [...]
>>
>>>>
>>>> Ok, let me go through my irc logs in case I find it.
>>>> Reading the email thread we should compile with anything > 8.1 right?
>>>>
>>>> Cheers
>>>> /Ilias
>>>>>
>>>>> --
>>>>> Tom
>>>
>>> Hi llias and Tom,
>>>
>>> I have a question might be wrong or not even exist.
>>> Tom mentioned GCC 8.1 kbuild but u-boot is considered as
>>> kernel build or it does not always be that case?
>>
>> We use the same Kbuild system as the kernel. I updated that a few
>> months ago since we where stuck on a really old version.
>>
>>>
>>> At least so fat there are nothing can build properly below 10.0.1
>>> Using ARM official cross compile binaries.
>>
>> I think I tested with gcc11, but I I don't remember testing with 8.x.
>> I probably missed something on the backporting. I'll try having a look
>>
>> Cheers
>> /Ilias
>>>
>>> Thanks,
>>> Brian
> 
> Thank you IIias I don't really know all the u-boot things.
> I had provided the first draft for fixing GCC check.
> https://patchwork.ozlabs.org/project/uboot/patch/20251202041029.186-1-briansune@gmail.com/
> Now it is on 10.0.1 if 8.1 is the case will update after your confirmation.
> 
> Thanks,
> Brian

I am able to build CycloneV with the later GCC 10.3 version on my side 
without this patch included in the patch series.

Thank you all for your valuable inputs.

Alif

Re: [PATCH v1 2/8] arm: Fix "file truncated" linker errors from empty built-in.a in SPL/TPL/VPL builds

[Sune Brian]

Yuslaimi, Alif Zakuan <alif.zakuan.yuslaimi@altera.com> 於 2025年12月3日週三 下午2:46寫道：
>
> Hi,
>
> On 2/12/2025 4:59 pm, Sune Brian wrote:
> > [CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
> >
> > Ilias Apalodimas <ilias.apalodimas@linaro.org> 於 2025年12月2日週二 下午4:53寫道：
> >>
> >> [...]
> >>
> >>>>
> >>>> Ok, let me go through my irc logs in case I find it.
> >>>> Reading the email thread we should compile with anything > 8.1 right?
> >>>>
> >>>> Cheers
> >>>> /Ilias
> >>>>>
> >>>>> --
> >>>>> Tom
> >>>
> >>> Hi llias and Tom,
> >>>
> >>> I have a question might be wrong or not even exist.
> >>> Tom mentioned GCC 8.1 kbuild but u-boot is considered as
> >>> kernel build or it does not always be that case?
> >>
> >> We use the same Kbuild system as the kernel. I updated that a few
> >> months ago since we where stuck on a really old version.
> >>
> >>>
> >>> At least so fat there are nothing can build properly below 10.0.1
> >>> Using ARM official cross compile binaries.
> >>
> >> I think I tested with gcc11, but I I don't remember testing with 8.x.
> >> I probably missed something on the backporting. I'll try having a look
> >>
> >> Cheers
> >> /Ilias
> >>>
> >>> Thanks,
> >>> Brian
> >
> > Thank you IIias I don't really know all the u-boot things.
> > I had provided the first draft for fixing GCC check.
> > https://patchwork.ozlabs.org/project/uboot/patch/20251202041029.186-1-briansune@gmail.com/
> > Now it is on 10.0.1 if 8.1 is the case will update after your confirmation.
> >
> > Thanks,
> > Brian
>
> I am able to build CycloneV with the later GCC 10.3 version on my side
> without this patch included in the patch series.
>
> Thank you all for your valuable inputs.
>
> Alif

Hi Alif

It is possible to align both sides with ARM official binary release?
The ARM have compressed cross-compiled binary.
10.0.1 should be the minimum it can runs.

[1] https://developer.arm.com/downloads/-/gnu-a

Thanks,
Brian

[PATCH v1 3/8] configs: cyclone5: Enable random MAC address

[alif.zakuan.yuslaimi]

From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>

Allow random MAC address assigned for ethernet initialization in CycloneV

Signed-off-by: Tien Fong Chee <tien.fong.chee@altera.com>
Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
---
 configs/socfpga_cyclone5_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
index 4a6f9b336cb..2bec82b0625 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -66,6 +66,8 @@ CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_MII=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM_RESET=y
 CONFIG_SPI=y
 CONFIG_CADENCE_QSPI=y
 CONFIG_DESIGNWARE_SPI=y
-- 
2.43.7

Re: [PATCH v1 3/8] configs: cyclone5: Enable random MAC address

[Marek Vasut]

On 11/25/25 9:13 AM, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> 
> Allow random MAC address assigned for ethernet initialization in CycloneV
Why ? The commit message should always explain the WHY .

Re: [PATCH v1 3/8] configs: cyclone5: Enable random MAC address

[Yuslaimi, Alif Zakuan]

Hi Marek,

On 25/11/2025 8:23 pm, Marek Vasut wrote:
> [CAUTION: This email is from outside your organization. Unless you trust 
> the sender, do not click on links or open attachments as it may be a 
> fraudulent email attempting to steal your information and/or compromise 
> your computer.]
> 
> On 11/25/25 9:13 AM, alif.zakuan.yuslaimi@altera.com wrote:
>> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>>
>> Allow random MAC address assigned for ethernet initialization in CycloneV
> Why ? The commit message should always explain the WHY .

Thanks for the comment, I will improve the commit message in v2.

Alif

[PATCH v1 4/8] mmc: socfpga_dw_mmc: Restore legacy clkmgr address retrieval

[alif.zakuan.yuslaimi]

From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>

Restore legacy implementation of retrieving clkmgr base address from
mach-socfpga/misc.c driver for our legacy devices.

Excluding Agilex7/7M from this implementation as these devices' clock
driver is already following clock driver model and is supporting
enable/disable APIs.

The legacy devices' clock driver will have to be refactored to support
driver model which enables us to support enable/disable APIs for these
devices.

Fixes: ab27182cac8f ("mmc: socfpga_dw_mmc: Enable/disable SDMMC clock via API")

Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
---
 drivers/mmc/socfpga_dw_mmc.c | 46 +++++++++++++++++++++++-------------
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index db4e0129c2e..6219284df3e 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -58,17 +58,24 @@ static int socfpga_dwmci_clksel(struct dwmci_host *host)
 	u32 sdmmc_mask = ((priv->smplsel & 0x7) << SYSMGR_SDMMC_SMPLSEL_SHIFT) |
 			 ((priv->drvsel & 0x7) << SYSMGR_SDMMC_DRVSEL_SHIFT);
 
-	ret = clk_get_by_name(priv->dev, "ciu", &priv->mmc_clk_ciu);
-	if (ret) {
-		debug("%s: Failed to get SDMMC clock from dts\n", __func__);
-		return ret;
-	}
-
-	/* Disable SDMMC clock. */
-	ret = clk_disable(&priv->mmc_clk_ciu);
-	if (ret) {
-		printf("%s: Failed to disable SDMMC clock\n", __func__);
-		return ret;
+	if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) &&
+	    !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M)) {
+		/* Disable SDMMC clock. */
+		clrbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
+			     CLKMGR_PERPLLGRP_EN_SDMMCCLK_MASK);
+	} else {
+		ret = clk_get_by_name(priv->dev, "ciu", &priv->mmc_clk_ciu);
+		if (ret) {
+			debug("%s: Failed to get SDMMC clock from dts\n", __func__);
+			return ret;
+		}
+
+		/* Disable SDMMC clock. */
+		ret = clk_disable(&priv->mmc_clk_ciu);
+		if (ret) {
+			printf("%s: Failed to disable SDMMC clock\n", __func__);
+			return ret;
+		}
 	}
 
 	debug("%s: drvsel %d smplsel %d\n", __func__,
@@ -88,11 +95,18 @@ static int socfpga_dwmci_clksel(struct dwmci_host *host)
 		readl(socfpga_get_sysmgr_addr() + SYSMGR_SDMMC));
 #endif
 
-	/* Enable SDMMC clock */
-	ret = clk_enable(&priv->mmc_clk_ciu);
-	if (ret) {
-		printf("%s: Failed to enable SDMMC clock\n", __func__);
-		return ret;
+	if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) &&
+	    !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M)) {
+		/* Enable SDMMC clock */
+		setbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
+			     CLKMGR_PERPLLGRP_EN_SDMMCCLK_MASK);
+	} else {
+		/* Enable SDMMC clock */
+		ret = clk_enable(&priv->mmc_clk_ciu);
+		if (ret) {
+			printf("%s: Failed to enable SDMMC clock\n", __func__);
+			return ret;
+		}
 	}
 
 	return 0;
-- 
2.43.7

Re: [PATCH v1 4/8] mmc: socfpga_dw_mmc: Restore legacy clkmgr address retrieval

[Marek Vasut]

On 11/25/25 9:13 AM, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> 
> Restore legacy implementation of retrieving clkmgr base address from
> mach-socfpga/misc.c driver for our legacy devices.
> 
> Excluding Agilex7/7M from this implementation as these devices' clock
> driver is already following clock driver model and is supporting
> enable/disable APIs.
> 
> The legacy devices' clock driver will have to be refactored to support
> driver model which enables us to support enable/disable APIs for these
> devices.
Ideally fix the clock driver instead of more ifdeffery.

Re: [PATCH v1 4/8] mmc: socfpga_dw_mmc: Restore legacy clkmgr address retrieval

[Yuslaimi, Alif Zakuan]

Hi Marek,

On 25/11/2025 8:24 pm, Marek Vasut wrote:
> [CAUTION: This email is from outside your organization. Unless you trust 
> the sender, do not click on links or open attachments as it may be a 
> fraudulent email attempting to steal your information and/or compromise 
> your computer.]
> 
> On 11/25/25 9:13 AM, alif.zakuan.yuslaimi@altera.com wrote:
>> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>>
>> Restore legacy implementation of retrieving clkmgr base address from
>> mach-socfpga/misc.c driver for our legacy devices.
>>
>> Excluding Agilex7/7M from this implementation as these devices' clock
>> driver is already following clock driver model and is supporting
>> enable/disable APIs.
>>
>> The legacy devices' clock driver will have to be refactored to support
>> driver model which enables us to support enable/disable APIs for these
>> devices.
> Ideally fix the clock driver instead of more ifdeffery.

This is intended as a temporary fix to unblock our partners which are 
using our legacy devices as we work on refactoring our clock drivers to 
support the driver model.

Once the clock drivers for our legacy devices (Stratix10, N5X, Arria10 
and CycloneV) are ready to support the APIs, we will clean up the code.

Thanks,
Alif

Re: [PATCH v1 4/8] mmc: socfpga_dw_mmc: Restore legacy clkmgr address retrieval

[Chee, Tien Fong]

On 25/11/2025 4:13 pm, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>
> Restore legacy implementation of retrieving clkmgr base address from
> mach-socfpga/misc.c driver for our legacy devices.
>
> Excluding Agilex7/7M from this implementation as these devices' clock
> driver is already following clock driver model and is supporting
> enable/disable APIs.
>
> The legacy devices' clock driver will have to be refactored to support
> driver model which enables us to support enable/disable APIs for these
> devices.
>
> Fixes: ab27182cac8f ("mmc: socfpga_dw_mmc: Enable/disable SDMMC clock via API")
>
> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> ---
>   drivers/mmc/socfpga_dw_mmc.c | 46 +++++++++++++++++++++++-------------
>   1 file changed, 30 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
> index db4e0129c2e..6219284df3e 100644
> --- a/drivers/mmc/socfpga_dw_mmc.c
> +++ b/drivers/mmc/socfpga_dw_mmc.c
> @@ -58,17 +58,24 @@ static int socfpga_dwmci_clksel(struct dwmci_host *host)
>   	u32 sdmmc_mask = ((priv->smplsel & 0x7) << SYSMGR_SDMMC_SMPLSEL_SHIFT) |
>   			 ((priv->drvsel & 0x7) << SYSMGR_SDMMC_DRVSEL_SHIFT);
>   
> -	ret = clk_get_by_name(priv->dev, "ciu", &priv->mmc_clk_ciu);
> -	if (ret) {
> -		debug("%s: Failed to get SDMMC clock from dts\n", __func__);
> -		return ret;
> -	}
> -
> -	/* Disable SDMMC clock. */
> -	ret = clk_disable(&priv->mmc_clk_ciu);
> -	if (ret) {
> -		printf("%s: Failed to disable SDMMC clock\n", __func__);
> -		return ret;
> +	if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) &&
> +	    !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M)) {
> +		/* Disable SDMMC clock. */
> +		clrbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
> +			     CLKMGR_PERPLLGRP_EN_SDMMCCLK_MASK);
> +	} else {
> +		ret = clk_get_by_name(priv->dev, "ciu", &priv->mmc_clk_ciu);
> +		if (ret) {
> +			debug("%s: Failed to get SDMMC clock from dts\n", __func__);
> +			return ret;
> +		}
> +
> +		/* Disable SDMMC clock. */
> +		ret = clk_disable(&priv->mmc_clk_ciu);
> +		if (ret) {
> +			printf("%s: Failed to disable SDMMC clock\n", __func__);
> +			return ret;
> +		}
>   	}
>   
>   	debug("%s: drvsel %d smplsel %d\n", __func__,
> @@ -88,11 +95,18 @@ static int socfpga_dwmci_clksel(struct dwmci_host *host)
>   		readl(socfpga_get_sysmgr_addr() + SYSMGR_SDMMC));
>   #endif
>   
> -	/* Enable SDMMC clock */
> -	ret = clk_enable(&priv->mmc_clk_ciu);
> -	if (ret) {
> -		printf("%s: Failed to enable SDMMC clock\n", __func__);
> -		return ret;
> +	if (!IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) &&
> +	    !IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX7M)) {
> +		/* Enable SDMMC clock */
> +		setbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
> +			     CLKMGR_PERPLLGRP_EN_SDMMCCLK_MASK);
> +	} else {
> +		/* Enable SDMMC clock */
> +		ret = clk_enable(&priv->mmc_clk_ciu);
> +		if (ret) {
> +			printf("%s: Failed to enable SDMMC clock\n", __func__);
> +			return ret;
> +		}
>   	}
>   
>   	return 0;


Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>

Best regards,
Tien Fong

[PATCH v1 5/8] spl: Remove ARCH_SOCFPGA from MMC raw mode enablement

[alif.zakuan.yuslaimi]

From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>

We no longer use raw mode to boot from MMC for our devices in favor
of FAT filesystem.

Maintaining this config for legacy gen5 devices as to not risk breaking
any configurations still utilizing raw mode.

Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
---
 common/spl/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index d24466b0c66..142cdb34cd5 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -545,7 +545,7 @@ config SPL_SYS_MMCSD_RAW_MODE
 	depends on SPL_DM_MMC || SPL_MMC
 	default y if ARCH_SUNXI || ARCH_DAVINCI || ARCH_UNIPHIER || \
 		     ARCH_MX6 || ARCH_MX7 || \
-		     ARCH_ROCKCHIP || ARCH_MVEBU ||  ARCH_SOCFPGA || \
+		     ARCH_ROCKCHIP || ARCH_MVEBU || TARGET_SOCFPGA_GEN5 || \
 		     ARCH_AT91 || ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || \
 		     OMAP54XX || AM33XX || AM43XX || \
 		     TARGET_SIFIVE_UNLEASHED || TARGET_SIFIVE_UNMATCHED
@@ -590,7 +590,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
 	default 0x8a if ARCH_MX6 || ARCH_MX7
 	default 0x100 if ARCH_UNIPHIER
 	default 0x0 if ARCH_MVEBU
-	default 0x200 if ARCH_SOCFPGA || ARCH_AT91
+	default 0x200 if TARGET_SOCFPGA_GEN5 || ARCH_AT91
 	default 0x300 if ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || \
 		         OMAP54XX || AM33XX || AM43XX || ARCH_K3
 	default 0x4000 if ARCH_ROCKCHIP
-- 
2.43.7

Re: [PATCH v1 5/8] spl: Remove ARCH_SOCFPGA from MMC raw mode enablement

[Chee, Tien Fong]

On 25/11/2025 4:13 pm, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>
> We no longer use raw mode to boot from MMC for our devices in favor
> of FAT filesystem.
>
> Maintaining this config for legacy gen5 devices as to not risk breaking
> any configurations still utilizing raw mode.
>
> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> ---
>   common/spl/Kconfig | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index d24466b0c66..142cdb34cd5 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -545,7 +545,7 @@ config SPL_SYS_MMCSD_RAW_MODE
>   	depends on SPL_DM_MMC || SPL_MMC
>   	default y if ARCH_SUNXI || ARCH_DAVINCI || ARCH_UNIPHIER || \
>   		     ARCH_MX6 || ARCH_MX7 || \
> -		     ARCH_ROCKCHIP || ARCH_MVEBU ||  ARCH_SOCFPGA || \
> +		     ARCH_ROCKCHIP || ARCH_MVEBU || TARGET_SOCFPGA_GEN5 || \
>   		     ARCH_AT91 || ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || \
>   		     OMAP54XX || AM33XX || AM43XX || \
>   		     TARGET_SIFIVE_UNLEASHED || TARGET_SIFIVE_UNMATCHED
> @@ -590,7 +590,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>   	default 0x8a if ARCH_MX6 || ARCH_MX7
>   	default 0x100 if ARCH_UNIPHIER
>   	default 0x0 if ARCH_MVEBU
> -	default 0x200 if ARCH_SOCFPGA || ARCH_AT91
> +	default 0x200 if TARGET_SOCFPGA_GEN5 || ARCH_AT91
>   	default 0x300 if ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || \
>   		         OMAP54XX || AM33XX || AM43XX || ARCH_K3
>   	default 0x4000 if ARCH_ROCKCHIP


Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>

Best regards,
Tien Fong

[PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[alif.zakuan.yuslaimi]

From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>

Enable support for FAT filesystem with SPL for CycloneV instead of raw
mode.

Recent changes breaks CycloneV MMC boot from raw mode, and so we are taking
this opportunity to migrate MMC boot mode to FAT as smaller OCRAM size is
required, as well as aligning MMC boot flow with our other devices.

Fixes: 2a00d73d081a1 ("spl: mmc: Try to clean up raw-mode options")

Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
---
 configs/socfpga_cyclone5_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
index 2bec82b0625..2b2435a27bb 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
 CONFIG_SPL_STACK=0x0
 CONFIG_SPL_TEXT_BASE=0xFFFF0000
 CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
+CONFIG_SPL_FS_FAT=y
 CONFIG_TIMESTAMP=y
 CONFIG_FIT=y
 CONFIG_DISTRO_DEFAULTS=y
@@ -27,6 +28,7 @@ CONFIG_SPL_PAD_TO=0x10000
 CONFIG_SPL_NO_BSS_LIMIT=y
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SPL_HAVE_INIT_STACK=y
+# CONFIG_SPL_SYS_MMCSD_RAW_MODE is not set
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
 CONFIG_SYS_MAXARGS=32
-- 
2.43.7

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Jan Kiszka]

On 25.11.25 09:13, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> 
> Enable support for FAT filesystem with SPL for CycloneV instead of raw
> mode.
> 
> Recent changes breaks CycloneV MMC boot from raw mode, and so we are taking
> this opportunity to migrate MMC boot mode to FAT as smaller OCRAM size is
> required, as well as aligning MMC boot flow with our other devices.
> 
> Fixes: 2a00d73d081a1 ("spl: mmc: Try to clean up raw-mode options")
> 
> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> ---
>  configs/socfpga_cyclone5_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
> index 2bec82b0625..2b2435a27bb 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
>  CONFIG_SPL_STACK=0x0
>  CONFIG_SPL_TEXT_BASE=0xFFFF0000
>  CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
> +CONFIG_SPL_FS_FAT=y
>  CONFIG_TIMESTAMP=y
>  CONFIG_FIT=y
>  CONFIG_DISTRO_DEFAULTS=y
> @@ -27,6 +28,7 @@ CONFIG_SPL_PAD_TO=0x10000
>  CONFIG_SPL_NO_BSS_LIMIT=y
>  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>  CONFIG_SPL_HAVE_INIT_STACK=y
> +# CONFIG_SPL_SYS_MMCSD_RAW_MODE is not set
>  CONFIG_SPL_SPI_LOAD=y
>  CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
>  CONFIG_SYS_MAXARGS=32

But what about other boards for the cycline5? If you want to switch,
switch them all. This looks half-backed.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Jan Kiszka]

On 25.11.25 10:41, Jan Kiszka wrote:
> On 25.11.25 09:13, alif.zakuan.yuslaimi@altera.com wrote:
>> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>>
>> Enable support for FAT filesystem with SPL for CycloneV instead of raw
>> mode.
>>
>> Recent changes breaks CycloneV MMC boot from raw mode, and so we are taking
>> this opportunity to migrate MMC boot mode to FAT as smaller OCRAM size is
>> required, as well as aligning MMC boot flow with our other devices.
>>
>> Fixes: 2a00d73d081a1 ("spl: mmc: Try to clean up raw-mode options")
>>
>> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>> ---
>>  configs/socfpga_cyclone5_defconfig | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
>> index 2bec82b0625..2b2435a27bb 100644
>> --- a/configs/socfpga_cyclone5_defconfig
>> +++ b/configs/socfpga_cyclone5_defconfig
>> @@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
>>  CONFIG_SPL_STACK=0x0
>>  CONFIG_SPL_TEXT_BASE=0xFFFF0000
>>  CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
>> +CONFIG_SPL_FS_FAT=y
>>  CONFIG_TIMESTAMP=y
>>  CONFIG_FIT=y
>>  CONFIG_DISTRO_DEFAULTS=y
>> @@ -27,6 +28,7 @@ CONFIG_SPL_PAD_TO=0x10000
>>  CONFIG_SPL_NO_BSS_LIMIT=y
>>  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>>  CONFIG_SPL_HAVE_INIT_STACK=y
>> +# CONFIG_SPL_SYS_MMCSD_RAW_MODE is not set
>>  CONFIG_SPL_SPI_LOAD=y
>>  CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
>>  CONFIG_SYS_MAXARGS=32
> 
> But what about other boards for the cycline5? If you want to switch,
> switch them all. This looks half-backed.
> 

BTW, the FAT refers to a u-boot.bin file on a fat partition, right? And
the SPL will be kept in the A2 raw partition then?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Chee, Tien Fong]

Hi Jan,

On 25/11/2025 5:44 pm, Jan Kiszka wrote:
> [CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
>
> On 25.11.25 10:41, Jan Kiszka wrote:
>> On 25.11.25 09:13, alif.zakuan.yuslaimi@altera.com wrote:
>>> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>>>
>>> Enable support for FAT filesystem with SPL for CycloneV instead of raw
>>> mode.
>>>
>>> Recent changes breaks CycloneV MMC boot from raw mode, and so we are taking
>>> this opportunity to migrate MMC boot mode to FAT as smaller OCRAM size is
>>> required, as well as aligning MMC boot flow with our other devices.
>>>
>>> Fixes: 2a00d73d081a1 ("spl: mmc: Try to clean up raw-mode options")
>>>
>>> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>>> ---
>>>   configs/socfpga_cyclone5_defconfig | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
>>> index 2bec82b0625..2b2435a27bb 100644
>>> --- a/configs/socfpga_cyclone5_defconfig
>>> +++ b/configs/socfpga_cyclone5_defconfig
>>> @@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
>>>   CONFIG_SPL_STACK=0x0
>>>   CONFIG_SPL_TEXT_BASE=0xFFFF0000
>>>   CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
>>> +CONFIG_SPL_FS_FAT=y
>>>   CONFIG_TIMESTAMP=y
>>>   CONFIG_FIT=y
>>>   CONFIG_DISTRO_DEFAULTS=y
>>> @@ -27,6 +28,7 @@ CONFIG_SPL_PAD_TO=0x10000
>>>   CONFIG_SPL_NO_BSS_LIMIT=y
>>>   # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>>>   CONFIG_SPL_HAVE_INIT_STACK=y
>>> +# CONFIG_SPL_SYS_MMCSD_RAW_MODE is not set
>>>   CONFIG_SPL_SPI_LOAD=y
>>>   CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
>>>   CONFIG_SYS_MAXARGS=32
>> But what about other boards for the cycline5? If you want to switch,
>> switch them all. This looks half-backed.
>>
> BTW, the FAT refers to a u-boot.bin file on a fat partition, right? And
> the SPL will be kept in the A2 raw partition then?

Yes, that’s correct. SPL remains in the raw/A2 partition as required by 
the Boot ROM. U-Boot proper is moved to a FAT32 partition.


Thanks.

Tien Fong

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Chee, Tien Fong]

Hi Jan,

On 25/11/2025 5:41 pm, Jan Kiszka wrote:
> [CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
>
> On 25.11.25 09:13, alif.zakuan.yuslaimi@altera.com wrote:
>> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>>
>> Enable support for FAT filesystem with SPL for CycloneV instead of raw
>> mode.
>>
>> Recent changes breaks CycloneV MMC boot from raw mode, and so we are taking
>> this opportunity to migrate MMC boot mode to FAT as smaller OCRAM size is
>> required, as well as aligning MMC boot flow with our other devices.
>>
>> Fixes: 2a00d73d081a1 ("spl: mmc: Try to clean up raw-mode options")
>>
>> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>> ---
>>   configs/socfpga_cyclone5_defconfig | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
>> index 2bec82b0625..2b2435a27bb 100644
>> --- a/configs/socfpga_cyclone5_defconfig
>> +++ b/configs/socfpga_cyclone5_defconfig
>> @@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
>>   CONFIG_SPL_STACK=0x0
>>   CONFIG_SPL_TEXT_BASE=0xFFFF0000
>>   CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
>> +CONFIG_SPL_FS_FAT=y
>>   CONFIG_TIMESTAMP=y
>>   CONFIG_FIT=y
>>   CONFIG_DISTRO_DEFAULTS=y
>> @@ -27,6 +28,7 @@ CONFIG_SPL_PAD_TO=0x10000
>>   CONFIG_SPL_NO_BSS_LIMIT=y
>>   # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>>   CONFIG_SPL_HAVE_INIT_STACK=y
>> +# CONFIG_SPL_SYS_MMCSD_RAW_MODE is not set
>>   CONFIG_SPL_SPI_LOAD=y
>>   CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
>>   CONFIG_SYS_MAXARGS=32
> But what about other boards for the cycline5? If you want to switch,
> switch them all. This looks half-backed.


The changes only affect the Altera official Cyclone V devkit. Other 
partner and vendor boards may have different MMC layouts, so we are not 
touching those in this patch.

The motivation is to enable FAT filesystem support for SPL on the 
official devkit, which reduces OCRAM usage, aligns the MMC boot flow 
with our other devkits, and avoids the raw-mode issues introduced by 
recent changes (mentioned in your series patches).


Thanks

Tien Fong

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Jan Kiszka]

On 27.11.25 05:32, Chee, Tien Fong wrote:
> Hi Jan,
> 
> On 25/11/2025 5:41 pm, Jan Kiszka wrote:
>> [CAUTION: This email is from outside your organization. Unless you
>> trust the sender, do not click on links or open attachments as it may
>> be a fraudulent email attempting to steal your information and/or
>> compromise your computer.]
>>
>> On 25.11.25 09:13, alif.zakuan.yuslaimi@altera.com wrote:
>>> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>>>
>>> Enable support for FAT filesystem with SPL for CycloneV instead of raw
>>> mode.
>>>
>>> Recent changes breaks CycloneV MMC boot from raw mode, and so we are
>>> taking
>>> this opportunity to migrate MMC boot mode to FAT as smaller OCRAM
>>> size is
>>> required, as well as aligning MMC boot flow with our other devices.
>>>
>>> Fixes: 2a00d73d081a1 ("spl: mmc: Try to clean up raw-mode options")
>>>
>>> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>>> ---
>>>   configs/socfpga_cyclone5_defconfig | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/
>>> socfpga_cyclone5_defconfig
>>> index 2bec82b0625..2b2435a27bb 100644
>>> --- a/configs/socfpga_cyclone5_defconfig
>>> +++ b/configs/socfpga_cyclone5_defconfig
>>> @@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
>>>   CONFIG_SPL_STACK=0x0
>>>   CONFIG_SPL_TEXT_BASE=0xFFFF0000
>>>   CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
>>> +CONFIG_SPL_FS_FAT=y
>>>   CONFIG_TIMESTAMP=y
>>>   CONFIG_FIT=y
>>>   CONFIG_DISTRO_DEFAULTS=y
>>> @@ -27,6 +28,7 @@ CONFIG_SPL_PAD_TO=0x10000
>>>   CONFIG_SPL_NO_BSS_LIMIT=y
>>>   # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>>>   CONFIG_SPL_HAVE_INIT_STACK=y
>>> +# CONFIG_SPL_SYS_MMCSD_RAW_MODE is not set
>>>   CONFIG_SPL_SPI_LOAD=y
>>>   CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
>>>   CONFIG_SYS_MAXARGS=32
>> But what about other boards for the cycline5? If you want to switch,
>> switch them all. This looks half-backed.
> 
> 
> The changes only affect the Altera official Cyclone V devkit. Other
> partner and vendor boards may have different MMC layouts, so we are not
> touching those in this patch.

But - as you introduced yourself - raw mode loading is broken for most
boards, specifically the DE0 Nano SoC. It uses sector-based raw mode by
default with an offset which only works by chance (if at all). If you
switch to partition ID mode (like the romloader), everything falls
apart. That's why I sent the other series. It may not yet be correct in
all details, though.

> 
> The motivation is to enable FAT filesystem support for SPL on the
> official devkit, which reduces OCRAM usage, aligns the MMC boot flow
> with our other devkits, and avoids the raw-mode issues introduced by
> recent changes (mentioned in your series patches).
> 

All fine, but please do it for all boards. I would not rely on partners
to do their homework here, otherwise things wouldn't have been broken
for more than a year now.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Sune Brian]

> But - as you introduced yourself - raw mode loading is broken for most
> boards, specifically the DE0 Nano SoC. It uses sector-based raw mode by
> default with an offset which only works by chance (if at all). If you
> switch to partition ID mode (like the romloader), everything falls
> apart. That's why I sent the other series. It may not yet be correct in
> all details, though.

Hi Jan,

No additional trouble on here but just want to
confirm how you run your DE0 board.

1) Do you use a pure MMC boot? (no NOR Flash)
2) You follow old boot flash method write
aka placing "u-boot-with-spl.sfp" to A2.
The "boot+rootfs" partition can be empty or
not exist.
So simply the entire sdmmc just contains A2 and
u-boot can't pass SPL phase enter U-Boot phase?
Are you having this trouble in the first place?

Thanks,
Brian

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Jan Kiszka]

On 27.11.25 07:48, Sune Brian wrote:
>> But - as you introduced yourself - raw mode loading is broken for most
>> boards, specifically the DE0 Nano SoC. It uses sector-based raw mode by
>> default with an offset which only works by chance (if at all). If you
>> switch to partition ID mode (like the romloader), everything falls
>> apart. That's why I sent the other series. It may not yet be correct in
>> all details, though.
> 
> Hi Jan,
> 
> No additional trouble on here but just want to
> confirm how you run your DE0 board.
> 
> 1) Do you use a pure MMC boot? (no NOR Flash)

Yes.

> 2) You follow old boot flash method write
> aka placing "u-boot-with-spl.sfp" to A2.
> The "boot+rootfs" partition can be empty or
> not exist.
> So simply the entire sdmmc just contains A2 and
> u-boot can't pass SPL phase enter U-Boot phase?
> Are you having this trouble in the first place?

I shared our wks file [1]: We create a raw partition in a legacy msdos
table, set its system ID to 0xa2 (via [2] when we use a hybrid partition
table, or classically [3] before that), and put u-boot-with-spl.sfp into
it. SPL is picked up by the romloader, but SPL in upstream completely
fails to find u-boot proper in that partition. And that is first of all
because SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is enabled by default which
ignores any partitioning and only uses a hard-coded sector. If one
switches to SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE mode, other
bugs after 2a00d73d081a surface like no longer built code or wrong
offsets inside the partition, and you also end up without u-boot proper
being found. Whatever other partitions or partition tables exist on the
SD card does not matter for SPL loading u-boot proper.

Jan

[1]
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/fa81b7aa856049af984f404047a2005d251b6072/wic/de0-nano-soc.wks
[2]
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/fa81b7aa856049af984f404047a2005d251b6072/scripts/lib/wic/plugins/source/de0-nano-soc-firmware.py
[3]
https://github.com/ilbers/isar/blob/master/meta-isar/scripts/lib/wic/canned-wks/de0-nano-soc.wks.in

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Sune Brian]

> I shared our wks file [1]: We create a raw partition in a legacy msdos
> table, set its system ID to 0xa2 (via [2] when we use a hybrid partition
> table, or classically [3] before that), and put u-boot-with-spl.sfp into
> it. SPL is picked up by the romloader, but SPL in upstream completely
> fails to find u-boot proper in that partition. And that is first of all
> because SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is enabled by default which
> ignores any partitioning and only uses a hard-coded sector. If one
> switches to SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE mode, other
> bugs after 2a00d73d081a surface like no longer built code or wrong
> offsets inside the partition, and you also end up without u-boot proper
> being found. Whatever other partitions or partition tables exist on the
> SD card does not matter for SPL loading u-boot proper.

Ha Now I see what you encounter.
No wonder. Because it is not supposed to run like that.
(i am no software experts)

I might be wrong, no shame on that I do simple software only.

So what T.F. had mentioned all aligned will all my build and
no additional patch is required from first place.

All there TYPE, #, OFFSET can work.
because it never uses the old method of combining.

A2 <- only SPL
FAT (boot) <- u-boot.img

Actually I mentioned this yesterday in our discussion. Maybe you
skipped that important information.

All board defconfig after 2025.05 is outdated; no one syncs those.

That's why I comment that the file "u-boot-with-spl.sfp" is misleading.
You have to turn on "FAT filesystems" change MMC boot partition
accordingly.

This is why I say this patch is not a must and combining SPL+UBOOT
to A2 is not really needed but only for backward build flow compatibility
concerns.

Bests,
Brian

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Jan Kiszka]

On 27.11.25 08:20, Sune Brian wrote:
>> I shared our wks file [1]: We create a raw partition in a legacy msdos
>> table, set its system ID to 0xa2 (via [2] when we use a hybrid partition
>> table, or classically [3] before that), and put u-boot-with-spl.sfp into
>> it. SPL is picked up by the romloader, but SPL in upstream completely
>> fails to find u-boot proper in that partition. And that is first of all
>> because SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is enabled by default which
>> ignores any partitioning and only uses a hard-coded sector. If one
>> switches to SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE mode, other
>> bugs after 2a00d73d081a surface like no longer built code or wrong
>> offsets inside the partition, and you also end up without u-boot proper
>> being found. Whatever other partitions or partition tables exist on the
>> SD card does not matter for SPL loading u-boot proper.
> 
> Ha Now I see what you encounter.
> No wonder. Because it is not supposed to run like that.
> (i am no software experts)
> 
> I might be wrong, no shame on that I do simple software only.
> 
> So what T.F. had mentioned all aligned will all my build and
> no additional patch is required from first place.
> 
> All there TYPE, #, OFFSET can work.
> because it never uses the old method of combining.
> 
> A2 <- only SPL
> FAT (boot) <- u-boot.img
> 
> Actually I mentioned this yesterday in our discussion. Maybe you
> skipped that important information.
> 
> All board defconfig after 2025.05 is outdated; no one syncs those.
> 
> That's why I comment that the file "u-boot-with-spl.sfp" is misleading.
> You have to turn on "FAT filesystems" change MMC boot partition
> accordingly.

This is not how upstream is currently configured. And upstream is the
reference because it not only sees vendor-related changes and decisions
but also other refactorings. And all those need to be kept in stable
state, irrespective of some random downstream trees. Actually, some of
the breakages I'm describing and trying to fix are not socfpga-only but
are conceptually affecting all boards that may use raw mmc loading today
or decide to do so in the future.

> 
> This is why I say this patch is not a must and combining SPL+UBOOT
> to A2 is not really needed but only for backward build flow compatibility
> concerns.

It is ok to work around current issues in upstream, but we still need to
fix raw mode loading - or drop it from the tree if it has no value
anymore (not my decision).

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Sune Brian]

> It is ok to work around current issues in upstream, but we still need to
> fix raw mode loading - or drop it from the tree if it has no value
> anymore (not my decision).
>
> Jan

No this is not a work around it is SPL seeking change from first place.
From the beginning, u-boot-with-spl.sfp is not supposed to exist
after 2025.05 or 2025.07 I forgot when the seek change from combine
to one out of three.

raw mode loading works, just combining two is no longer an option from
first place. My understanding as such.

I don;t think you had encountered SPL not beginning printout aka load.

Brian

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Jan Kiszka]

On 27.11.25 08:39, Sune Brian wrote:
>> It is ok to work around current issues in upstream, but we still need to
>> fix raw mode loading - or drop it from the tree if it has no value
>> anymore (not my decision).
>>
>> Jan
> 
> No this is not a work around it is SPL seeking change from first place.
> From the beginning, u-boot-with-spl.sfp is not supposed to exist
> after 2025.05 or 2025.07 I forgot when the seek change from combine
> to one out of three.
> 
> raw mode loading works, just combining two is no longer an option from
> first place. My understanding as such.
> 
> I don;t think you had encountered SPL not beginning printout aka load.
> 

I would recommend studying my raw-mode loading patches without looking
too closely at your own setup again. You should be able to spot the bugs
I try to fix there.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Sune Brian]

> I would recommend studying my raw-mode loading patches without looking
> too closely at your own setup again. You should be able to spot the bugs
> I try to fix there.
>
> Jan

Open minded, point out which one please?
But since 2025 07 I did not encounter any major issue.
On mainstream. Maybe your patch dates before that?

Thanks,
Brian

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Jan Kiszka]

On 27.11.25 08:56, Sune Brian wrote:
>> I would recommend studying my raw-mode loading patches without looking
>> too closely at your own setup again. You should be able to spot the bugs
>> I try to fix there.
>>
>> Jan
> 
> Open minded, point out which one please?
> But since 2025 07 I did not encounter any major issue.
> On mainstream. Maybe your patch dates before that?
> 

My patches address master (of two weeks ago at least). Please have a
look at
https://lore.kernel.org/u-boot/cover.1763140421.git.jan.kiszka@siemens.com/
(or https://patchwork.ozlabs.org/project/uboot/list/?series=482132), and
if you find something that is changing in the wrong direction, please
comment on it. There is at least one known build issue when you disable
CONFIG_SYS_MMCSD_RAW_MODE.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Sune Brian]

> My patches address master (of two weeks ago at least). Please have a
> look at
> https://lore.kernel.org/u-boot/cover.1763140421.git.jan.kiszka@siemens.com/
> (or https://patchwork.ozlabs.org/project/uboot/list/?series=482132), and
> if you find something that is changing in the wrong direction, please
> comment on it. There is at least one known build issue when you disable
> CONFIG_SYS_MMCSD_RAW_MODE.
>
> Jan

Will take a look more a bit.
Before that I want to confirm s.t.
You want all three modes to support combined SPL+UBOOT
aka u-boot-with-spl.sfp in A2 parition?
So simply speaking you don't want u-boot.img in FAT?

Thanks
Brian

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Jan Kiszka]

On 27.11.25 10:42, Sune Brian wrote:
>> My patches address master (of two weeks ago at least). Please have a
>> look at
>> https://lore.kernel.org/u-boot/cover.1763140421.git.jan.kiszka@siemens.com/
>> (or https://patchwork.ozlabs.org/project/uboot/list/?series=482132), and
>> if you find something that is changing in the wrong direction, please
>> comment on it. There is at least one known build issue when you disable
>> CONFIG_SYS_MMCSD_RAW_MODE.
>>
>> Jan
> 
> Will take a look more a bit.
> Before that I want to confirm s.t.
> You want all three modes to support combined SPL+UBOOT
> aka u-boot-with-spl.sfp in A2 parition?
> So simply speaking you don't want u-boot.img in FAT?

I want something booting. If I had known earlier that FAT is working and
not generating too large SPLs (e.g. if the default board config had
changed...), I would have stopped using raw mode.

Now, let's assume someone still wants raw mode (and [1] suggests that
there might be cases), the raw sector mode is not so desirable because
it forces you to place the binary at a specific location on the disk,
requiring that to be synchronized with your image layout (such as a wks
file). Given that the romloader happily uses part-by-id, I would prefer
that for the SPL as well. Still, if someone configures another mode,
that should still work (when providing the right magic sector value).

Jan

[1]
https://lore.kernel.org/u-boot/85b3b8a8-fbaf-4e30-a38b-af4299820487@siemens.com/

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Sune Brian]

> Now, let's assume someone still wants raw mode (and [1] suggests that
> there might be cases), the raw sector mode is not so desirable because
> it forces you to place the binary at a specific location on the disk,
> requiring that to be synchronized with your image layout (such as a wks
> file). Given that the romloader happily uses part-by-id, I would prefer
> that for the SPL as well. Still, if someone configures another mode,
> that should still work (when providing the right magic sector value).

Doesn't matter I had completed all three modes boot with minimum
change on latest u-boot. I do check your patch include indeed is
bug. I will pass out patches and this group members should help a bit.
Just need to finish checking that the fat boot is not affected.
Old u-boot-with-spl.sfp on my patches should run w/o issue.

I will acknowledge your work with no worries. Then let T.F. see which
is better for u-boot mainstream as well as Tom.

Thanks,
Brian

Re: [PATCH v1 6/8] configs: cyclone5: Enable SPL FAT support

[Chee, Tien Fong]

On 25/11/2025 4:13 pm, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>
> Enable support for FAT filesystem with SPL for CycloneV instead of raw
> mode.
>
> Recent changes breaks CycloneV MMC boot from raw mode, and so we are taking
> this opportunity to migrate MMC boot mode to FAT as smaller OCRAM size is
> required, as well as aligning MMC boot flow with our other devices.
>
> Fixes: 2a00d73d081a1 ("spl: mmc: Try to clean up raw-mode options")
>
> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> ---
>   configs/socfpga_cyclone5_defconfig | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
> index 2bec82b0625..2b2435a27bb 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
>   CONFIG_SPL_STACK=0x0
>   CONFIG_SPL_TEXT_BASE=0xFFFF0000
>   CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
> +CONFIG_SPL_FS_FAT=y
>   CONFIG_TIMESTAMP=y
>   CONFIG_FIT=y
>   CONFIG_DISTRO_DEFAULTS=y
> @@ -27,6 +28,7 @@ CONFIG_SPL_PAD_TO=0x10000
>   CONFIG_SPL_NO_BSS_LIMIT=y
>   # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
>   CONFIG_SPL_HAVE_INIT_STACK=y
> +# CONFIG_SPL_SYS_MMCSD_RAW_MODE is not set
>   CONFIG_SPL_SPI_LOAD=y
>   CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
>   CONFIG_SYS_MAXARGS=32


Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>

Best regards,
Tien Fong

[PATCH v1 7/8] configs: cyclone5: Update boot command for CycloneV

[alif.zakuan.yuslaimi]

From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>

Update CycloneV boot command to sync with Altera official release

Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
---
 configs/socfpga_cyclone5_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
index 2b2435a27bb..94bb05d20ff 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -16,7 +16,7 @@ CONFIG_SPL_FS_FAT=y
 CONFIG_TIMESTAMP=y
 CONFIG_FIT=y
 CONFIG_DISTRO_DEFAULTS=y
-# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_BOOTCOMMAND="run fatscript;bridge enable; run distro_bootcmd"
 CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_socdk.dtb"
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-- 
2.43.7

Re: [PATCH v1 7/8] configs: cyclone5: Update boot command for CycloneV

[Chee, Tien Fong]

On 25/11/2025 4:13 pm, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>
> Update CycloneV boot command to sync with Altera official release
>
> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> ---
>   configs/socfpga_cyclone5_defconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
> index 2b2435a27bb..94bb05d20ff 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -16,7 +16,7 @@ CONFIG_SPL_FS_FAT=y
>   CONFIG_TIMESTAMP=y
>   CONFIG_FIT=y
>   CONFIG_DISTRO_DEFAULTS=y
> -# CONFIG_USE_BOOTCOMMAND is not set
> +CONFIG_BOOTCOMMAND="run fatscript;bridge enable; run distro_bootcmd"
>   CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_socdk.dtb"
>   CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>   CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y


Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>

Best regards,
Tien Fong

[PATCH v1 8/8] configs: cyclone5: Disable SPI in SPL

[alif.zakuan.yuslaimi]

From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>

Disable support for using SPI in SPL to solve Cyclone V storage issue as
the OCRAM is only 64kb. The SPI configurations are only
required during uboot proper only.

Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
---
 configs/socfpga_cyclone5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
index 94bb05d20ff..6d9acf6c231 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
 CONFIG_SPL_STACK=0x0
 CONFIG_SPL_TEXT_BASE=0xFFFF0000
 CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
+# CONFIG_SPL_SPI is not set
 CONFIG_SPL_FS_FAT=y
 CONFIG_TIMESTAMP=y
 CONFIG_FIT=y
-- 
2.43.7

Re: [PATCH v1 8/8] configs: cyclone5: Disable SPI in SPL

[Chee, Tien Fong]

On 25/11/2025 4:13 pm, alif.zakuan.yuslaimi@altera.com wrote:
> From: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
>
> Disable support for using SPI in SPL to solve Cyclone V storage issue as
> the OCRAM is only 64kb. The SPI configurations are only
> required during uboot proper only.
>
> Signed-off-by: Alif Zakuan Yuslaimi <alif.zakuan.yuslaimi@altera.com>
> ---
>   configs/socfpga_cyclone5_defconfig | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig
> index 94bb05d20ff..6d9acf6c231 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -12,6 +12,7 @@ CONFIG_DM_RESET=y
>   CONFIG_SPL_STACK=0x0
>   CONFIG_SPL_TEXT_BASE=0xFFFF0000
>   CONFIG_TARGET_SOCFPGA_CYCLONE5_SOCDK=y
> +# CONFIG_SPL_SPI is not set
>   CONFIG_SPL_FS_FAT=y
>   CONFIG_TIMESTAMP=y
>   CONFIG_FIT=y


Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>

Best regards,
Tien Fong