[PATCH 2/2] Fix x86 baytrail boot flow, UPD/VPD Updates

[Eric Schikschneit]

Hello Simon, Tom,

1. Tom -
> And we should spell out that device tree can't set these any more in the
> commit message, along with spelling out why we can't do that anymore
> safely (why can't we?). Thanks.
I would be happy to move the code comment into the commit message:
 /* NOTE: This breaks u-boot ability to set board options via    *
  * device tree, but guarantees specific known values..          *
  * you wouldnt use an uninitialized variable would you??        */
These settings could be set by device tree, but every fdtdec* function must
set a valid value. If a user has something set differently than called out in the
FSP_MR5 Integration Guide the board stability will be compromised. Many of
these settings are co-dependant so we would need much more robust error
checking. This task would not be trivial. By using the specific values called out
by the Integration guide we allow users to begin from a documented known
good configuration. Maybe we could set all the values, and then check the
device tree to see if the user specified a different value? If the device tree does
not call out a specific setting we would not want to just set it to zero for example
as this can cause undefined behavior.

Eric Schikschneit
Senior Embedded Linux Engineer III  ​

________________________________________
From: Simon Glass <sjg at chromium.org>
Sent: Tuesday, February 3, 2026 3:29 PM
To: Tom Rini
Cc: Eric Schikschneit; u-boot at lists.denx.de; bmeng.cn at gmail.com
Subject: Re: [PATCH 2/2] Fix x86 baytrail boot flow, UPD/VPD Updates

Hi,

On Wed, 4 Feb 2026 at 07:14, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Jul 14, 2025 at 04:02:49PM -0500, Eric Schikschneit wrote:
>
> > The VPD has been updated to include additional values found in the Intel
> > FSP_MR5 Integration Guide.
> >
> > Disable MRC_CACHE for the baytrail platform as this will break the boot flow
> > as well. This issue has not been diagnosed further, but I suspect it is similar
> > to my previous patch and related to how modern GCC generates the low level
> > op-codes.
> >
> > Patch 2 of 2
> >
> > Upstream-Status: Pending
> >
> > Signed-off-by: Eric Schikschneit <eric.schikschneit at novatechautomation.com>
> [snip]
> > +     /* Set all values to known good defaults as documented in       *
> > +      * Intel FSP_MR5 file: BAYTRAIL_FSP.bsf                         */
> > +
> > +     /* NOTE: This breaks u-boot ability to set board options via    *
> > +      * device tree, but guarantees specific known values..          *
> > +      * you wouldnt use an uninitialized variable would you??        */
>
> /*
>  * Multi-line comments like this please per
>  * https://docs.u-boot.org/en/latest/develop/codingstyle.html
>  */
>
> And we should spell out that device tree can't set these any more in the
> commit message, along with spelling out why we can't do that anymore
> safely (why can't we?). Thanks.

Again I am not seeing this problem with minnowmax, so would like a few
more details.

Regards,
Simon