Hi,
On 4/2/23 21:16, Simon Glass wrote:
Hi Tom,
On Mon, 3 Apr 2023 at 02:42, Tom Rini trini@konsulko.com wrote:
On Sun, Apr 02, 2023 at 02:41:46PM +1200, Simon Glass wrote:
Hi Mark,
On Sun, 2 Apr 2023 at 10:31, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Sun, 2 Apr 2023 09:45:33 +1200
Since CONFIG_BOOTSTD_DEFAULTS now selects ENV_VARS_UBOOT_CONFIG we
cannot
enable it for some Xilinx boards which have a very small environment.
Disable it.
Does that mean these configs lose distroboot support? That would be a shame!
We use 'select' to enable things, so we don't have the ability to enable just some of the defaults. So unfortunately this board needs to have BOOTSTD_DEFAULTS disabled.
It certainly doesn't have anywhere near enough env space for distroboot, although I'm not sure why it is so limited.
Distroboot seems to work historically on this platform, so you need to ensure it still works afterwards. These platforms just don't enable the "enable all the options" option because they're intentionally limited (the "mini" in the name).
It looks like they set the bootcommand to 'run distro_bootcmd' rather than enabling DISTRO_DEFAULTS.
But I just don't understand how it can work. The env size is 0x80 bytes and it doesn't include the config_distro_bootcmd.h file.
Mark, maybe I just totally lost, but I just cannot see how this can work. Please take a look.
Tom, do you have a board to test with?
Anyway, as should be clear from my commit message, this is about BOOTSTD_DEFAULTS so it does not affect DISTRO_DEFAULTS.
mini configuration are used for non volatile memories programming. They are only designed for it. They are running out of OCM without any intention to boot any other SW. That's why disabling any configuration related to distro boot is the right way to go.
Acked-by: Michal Simek michal.simek@amd.com
Thanks, Michal