[PATCH 1/2] Fix x86 baytrail boot flow.

[Eric Schikschneit]

Hello Simon, Tom,

I am getting back to this and will try to answer your questions the best I can. It has been quite some time since I was deep into this code.

1. Tom - 
> Doing it this way will break other architectures. Can we just call the
> function needed inside of x86 assembly?
I suppose we could do something like that. What do you suggest? A new .S assembly file?

2. Simon -
> Are you using the embedded toolchain, or just the host compiler?
I was using the host compiler packaged in Ubuntu 22.04 which at the time was GCC 11.4.0.
I have moved to Ubuntu 24.04.3 LTS which has GCC 11.5.0 currently. If you would like me to
test using a specific compiler and / or toolchain please let me know! Also I noticed you are
testing against: "U-Boot 2026.01-rc5" and according to my notes, and git history it appears
I was working with v2024.04 at the time. As we move forward with this I can do tests against
the latest version. Do you have a specific commit you would like me to test from, or just master
branch tip?


Eric Schikschneit
Senior Embedded Linux Engineer III  ​
 
________________________________________
From: Simon Glass <sjg at chromium.org>
Sent: Tuesday, February 3, 2026 3:28 PM
To: Tom Rini
Cc: Eric Schikschneit; u-boot at lists.denx.de; bmeng.cn at gmail.com
Subject: Re: [PATCH 1/2] Fix x86 baytrail boot flow.

Hi,

On Wed, 4 Feb 2026 at 07:02, Tom Rini <trini at konsulko.com> 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 <eric.schikschneit at novatechautomation.com>
>
> 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