Re: U-boot version selection

[Joel Stanley <joel@jms.id.au>]

egacOn Thu, 1 Jul 2021 at 02:48, Zev Weiss <zweiss@equinix.com> wrote:
>
> Hi,
>
> I recently found myself needing to make some tweaks to u-boot to
> accommodate a new board I'm targeting with a larger flash part, but in
> going to do so I remembered that I'm currently using u-boot v2016.7,
> whereas new development is strongly encouraged to use v2019.04 [1].
>
> As far as I know that happened entirely by default (i.e. I didn't go out
> of my way to use the older version), so I hunted around a bit for how to
> override that to use the newer one, but wasn't able to find anything
> obvious.  What's the recommended way to go about switching that for my
> board?

You can see Lei's change to use the newer tree here:

 https://github.com/openbmc/openbmc/commit/1aa72efd0f54

UBOOT_DEVICETREE = "ast2500-evb"
UBOOT_MACHINE = "evb-ast2500_defconfig"

PREFERRED_PROVIDER_u-boot = "u-boot-aspeed-sdk"
PREFERRED_PROVIDER_u-boot-fw-utils = "u-boot-fw-utils-aspeed-sdk"
PREFERRED_PROVIDER_virtual/bootloader = "u-boot-aspeed-sdk"

The important change is to point it to a valid defconfig for the new
tree, to specify the u-boot device tree to use, and to change some
yocto PROVIDER variables to use the "u-boot-aspeed-sdk" variant.

Currently there's only one machine defined in the u-boot tree, for the
evb. We will need a new machine defined if your system uses NCSI for
networking.

We could use a common configuration for NCSI and non-NCSI (direct
attached PHY) systems, except for one bug. The NCSI layer as it is
currently implemented will cause the networking layer to attempt to
initalise NCSI, even if your device tree says you have no NCSI
devices. We will need to make a code change to fix this.

The offending code snippet is in net/net.c:

+       if (protocol != NCSI && !ncsi_active()) {
+               printf("%s: configuring NCSI first\n", __func__);
+               if (net_loop(NCSI) < 0)
+                       return ret;
+               eth_init_state_only();
+               goto restart;
+       }

The fix would be to add a new test to ncsi_active that returns "true"
if there are no ncsi capable devices in the system.

It would make sense to rename the function too, but the core of the
change is to ensure we don't require ncsi to be active if it's not
being used.

> And do we want to consider changing the default to the newer branch?

Yes! I think this would be a great idea. Ideally we would have people
switch over to using the new tree, but this is unlikely to happen.
Best would be to make it the default so new machines opt for the newer
tree, and legacy machines can use the outdated tree.

This would require us to add something like the following to all of
the legacy aspeed machines:

PREFERRED_PROVIDER_u-boot = "u-boot-aspeed"
PREFERRED_PROVIDER_u-boot-fw-utils = "u-boot-fw-utils-aspeed"
PREFERRED_PROVIDER_virtual/bootloader = "u-boot-aspeed"

Once that is done, we could change the following in meta-aspeed:

--- a/meta-aspeed/conf/machine/include/aspeed.inc
+++ b/meta-aspeed/conf/machine/include/aspeed.inc
@@ -1,7 +1,7 @@
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-aspeed"
-PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-aspeed"
-PREFERRED_PROVIDER_u-boot ?= "u-boot-aspeed"
-PREFERRED_PROVIDER_u-boot-fw-utils ?= "u-boot-fw-utils-aspeed"
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-aspeed-sdk"
+PREFERRED_PROVIDER_u-boot ?= "u-boot-aspeed-sdk"
+PREFERRED_PROVIDER_u-boot-fw-utils ?= "u-boot-fw-utils-aspeed-sdk"