* U-boot version selection @ 2021-07-01 2:42 Zev Weiss 2021-07-01 4:51 ` Joel Stanley 0 siblings, 1 reply; 4+ messages in thread From: Zev Weiss @ 2021-07-01 2:42 UTC (permalink / raw) To: openbmc 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: U-boot version selection 2021-07-01 2:42 U-boot version selection Zev Weiss @ 2021-07-01 4:51 ` Joel Stanley 2021-07-08 19:19 ` Zev Weiss 0 siblings, 1 reply; 4+ messages in thread From: Joel Stanley @ 2021-07-01 4:51 UTC (permalink / raw) To: Zev Weiss, 郁雷; +Cc: openbmc 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" ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: U-boot version selection 2021-07-01 4:51 ` Joel Stanley @ 2021-07-08 19:19 ` Zev Weiss 2021-07-12 10:31 ` Joel Stanley 0 siblings, 1 reply; 4+ messages in thread From: Zev Weiss @ 2021-07-08 19:19 UTC (permalink / raw) To: Joel Stanley; +Cc: openbmc, 郁雷 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: U-boot version selection 2021-07-08 19:19 ` Zev Weiss @ 2021-07-12 10:31 ` Joel Stanley 0 siblings, 0 replies; 4+ messages in thread From: Joel Stanley @ 2021-07-12 10:31 UTC (permalink / raw) To: Zev Weiss; +Cc: openbmc, 郁雷 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-07-12 10:32 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-01 2:42 U-boot version selection Zev Weiss 2021-07-01 4:51 ` Joel Stanley 2021-07-08 19:19 ` Zev Weiss 2021-07-12 10:31 ` Joel Stanley
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).