archive mirror
 help / color / mirror / Atom feed
From: Joel Stanley <>
To: "Zev Weiss" <>, 郁雷 <>
Cc: "" <>
Subject: Re: U-boot version selection
Date: Thu, 1 Jul 2021 04:51:49 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210701024206.GH8018@packtop>

egacOn Thu, 1 Jul 2021 at 02:48, Zev Weiss <> 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:

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

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/
+++ b/meta-aspeed/conf/machine/include/
@@ -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"

  reply	other threads:[~2021-07-01  4:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  2:42 U-boot version selection Zev Weiss
2021-07-01  4:51 ` Joel Stanley [this message]
2021-07-08 19:19   ` Zev Weiss
2021-07-12 10:31     ` Joel Stanley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).