Hi, On Wed, 4 Feb 2026 at 07:02, Tom Rini <[email protected]> wrote: > > On Mon, Jul 14, 2025 at 04:02:48PM -0500, Eric Schikschneit wrote: > > > It was found that on modern versions of GCC the transition from low level > > assembly into the C function 'fsp_find_header' was no longer valid. A > > detailed > > step by step analysis with GDB showed that various registers were not being > > initialized properly which would result in the hardware to fail to setup the > > Cache As Ram (CAR) portion. This failure cascades down into later stages of > > initialization because there is no valid stack, or memory for later > > functions. > > > > The function 'fsp_find_header' has been rewritten in assembly, which should > > no longer be dependant on a specific version of GCC in order to be usable on > > actual hardware. > > > > Testing was done using GCC 11.4.0 on Ubuntu 22.04. > > Hardware used for verification: Intel E3845 SoC > > > > Patch 1 of 2 > > > > Upstream-Status: Pending > > > > Signed-off-by: Eric Schikschneit <[email protected]> > > Sorry for the delayed response here. > > [snip] > > diff --git a/common/board_f.c b/common/board_f.c > > index 442b8349d08..3a9ae741d97 100644 > > --- a/common/board_f.c > > +++ b/common/board_f.c > > @@ -860,6 +860,7 @@ __weak int clear_bss(void) > > } > > > > static const init_fnc_t init_sequence_f[] = { > > + arch_fsp_init, // FSP on platforms like baytrail MUST be > > done before memory ops > > setup_mon_len, > > #ifdef CONFIG_OF_CONTROL > > fdtdec_setup, > > diff --git a/include/init.h b/include/init.h > > index 9a1951d10a0..21d9cea30f6 100644 > > --- a/include/init.h > > +++ b/include/init.h > > @@ -68,6 +68,15 @@ int mach_cpu_init(void); > > */ > > int arch_fsp_init_r(void); > > > > +/** > > + * arch_fsp_init() - perform firmware support package init > > + * > > + * Where U-Boot relies on binary blobs to handle part of the system init, > > this > > + * function can be used to set up the blobs. This is used on some Intel > > + * platforms. > > + */ > > +int arch_fsp_init(void); > > + > > int dram_init(void); > > > > /** > > Doing it this way will break other architectures. Can we just call the > function needed inside of x86 assembly?
Also I wonder what is different here. Is it a bug in gcc or something else. When I try -next on minnowmax I see some errors, but it does boot: $ ub-int minnowmax Building U-Boot in sourcedir for minnowmax Bootstrapping U-Boot from dir /tmp/b/minnowmax Writing U-Boot using method em100 Bloblist at 0 not found (err=-2) alloc space exhausted ptr 400 limit 0 Bloblist at 0 not found (err=-2) Bloblist at 0 not found (err=-2) alloc space exhausted ptr 400 limit 0 Bloblist at 0 not found (err=-2) U-Boot 2026.01-rc5-00488-g6cdd7597a2fb (Feb 03 2026 - 14:20:37 -0700) CPU: Intel(R) Atom(TM) CPU E3825 @ 1.33GHz DRAM: 2 GiB (total 1.9 GiB) Core: 25 devices, 16 uclasses, devicetree: separate MMC: pci_mmc: 0, pci_mmc: 1, pci_mmc: 2 Loading Environment from SPIFlash... SF: Detected w25q64dw with page size 256 Bytes, erase size 4 KiB, total 8 MiB *** Warning - bad CRC, using default environment Model: Intel Minnowboard Max Net: eth0: eth_rtl8169 Hit any key to stop autoboot: 0 => This is with ~/..buildman-toolchains/gcc-13.2.0-nolibc/i386-linux/bin/i386-linux- but I also tried with ~/.buildman-toolchains/gcc-11.1.0-nolibc/i386-linux/bin/i386-linux- and got the same result. I wonder if this is a bug in that particular version. Are you using the embedded toolchain, or just the host compiler? Both should normally work though... Regards, Simon
