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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260213/2ef23d76/attachment.sig>