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

[Simon Glass]

Hi Tom,

On Fri, 13 Feb 2026 at 11:14, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Feb 13, 2026 at 10:53:26AM -0700, Simon Glass wrote:
> > Hi Eric,
> >
> > On Tue, 10 Feb 2026 at 07:38, Eric Schikschneit
> > <eric.schikschneit at novatechautomation.com> wrote:
> > >
> > > 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.
> >
> > The device tree is actually where these values are set for all x86
> > boards. If you change any value in a device tree you risk bricking any
> > board. It should be considered an integral part of the build. If you
> > change the C code you can also brick a board.
> >
> > So I don't like the idea of changing this to C, sorry.
> >
> > NAK from me sorry.
>
> Let us not be hasty here. It sounds like we're getting some feedback
> from production users of this support finally and not just people like
> you and I that had reflashed our Minnowboards or similar to prove it
> worked.
>

OK.

Regards,
Simon