U-boot version selection

U-boot version selection

[Zev Weiss]

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?  And do we want to consider changing the default to the newer
branch?


Thanks,
Zev


[1] https://lore.kernel.org/openbmc/CACPK8XfcTXsdSviy1WGdXgkrHYQR924bpst7zeeK0bxT5MOTAw@mail.gmail.com/

Re: U-boot version selection

[Joel Stanley]

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"

Re: U-boot version selection

[Zev Weiss]

On Wed, Jun 30, 2021 at 11:51:49PM CDT, Joel Stanley wrote:
>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.
>

Great, thanks for the pointers there -- that worked smoothly on the 64M
board I'm currently working on a port for.  Unfortunately when I tried
it out on one of the 32M platforms I've got I realized that the u-boot
image with the new branch comes out to around 430K, which in addition to
being quite a bit larger than the old branch (~225K), is too big to fit
in the u-boot partition of the 32MB static flash layout (384K).

With a bit of haphazard experimentation, I found that disabling
CONFIG_EFI_LOADER got it down to 370K, and turning off
CONFIG_SYS_LONGHELP reduced that to 357K, leaving a bit of breathing
room, though perhaps still less than would be ideal.  Since a quick poll
of FLASH_SIZE settings seems to indicate that most existing OpenBMC
platforms are 32M, would those be appropriate candidates to add to the
evb-ast2500_defconfig?

(I also encountered an ftgmac100 phy-related null pointer dereference
that leads to it spewing a bunch of garbage to the console, which I
band-aided temporarily with a dts patch to disable the second mac.)


Zev

Re: U-boot version selection

[Joel Stanley]

On Thu, 8 Jul 2021 at 19:19, Zev Weiss <zweiss@equinix.com> wrote:
>
> On Wed, Jun 30, 2021 at 11:51:49PM CDT, Joel Stanley wrote:
> >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.
> >
>
> Great, thanks for the pointers there -- that worked smoothly on the 64M
> board I'm currently working on a port for.  Unfortunately when I tried
> it out on one of the 32M platforms I've got I realized that the u-boot
> image with the new branch comes out to around 430K, which in addition to
> being quite a bit larger than the old branch (~225K), is too big to fit
> in the u-boot partition of the 32MB static flash layout (384K).
>
> With a bit of haphazard experimentation, I found that disabling
> CONFIG_EFI_LOADER got it down to 370K, and turning off
> CONFIG_SYS_LONGHELP reduced that to 357K, leaving a bit of breathing
> room, though perhaps still less than would be ideal.  Since a quick poll
> of FLASH_SIZE settings seems to indicate that most existing OpenBMC
> platforms are 32M, would those be appropriate candidates to add to the
> evb-ast2500_defconfig?

Yes, that would make sense. Confirming that this set got it down to 345 KB:

+# CONFIG_SYS_LONGHELP is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_REGEX is not set
+# CONFIG_EFI_LOADER is not set

Are there any ast2500 boards that use MMC? If not, disabling MMC and
block devices gets it down to 321 KB:

-CONFIG_CMD_MMC=y
-CONFIG_DM_MMC=y
-# CONFIG_MMC_HW_PARTITIONING is not set
-CONFIG_MMC_SDHCI=y
-CONFIG_MMC_SDHCI_ASPEED=y
+# CONFIG_MMC is not set

If we disable MMC, we should probably create our own defconfig
(ast2500_openbmc_defconifg). If we just want to disable the unused
options, I think patching the evb defconfig is fine. I'll leave it to
you; please send a patch to the list and I'll merge it.

>
> (I also encountered an ftgmac100 phy-related null pointer dereference
> that leads to it spewing a bunch of garbage to the console, which I
> band-aided temporarily with a dts patch to disable the second mac.)

Thanks for the report.