kernel: banner: Allow for external boot banner

[nordicjm]

Adds a new Kconfig CONFIG_BOOT_BANNER_EXTERNAL_IMPLEMENTATION which
allows for applications/modules to implement their own boot banner

Also includes fix for MCUboot

Background:

MCUboot has had a custom boot banner added which replaces the zephyr one to include information on the MCUboot build, with a normal zephyr build this works fine due to the linker dropping the original function and using the one that MCUboot has, but with llext enabled in the build, the build fails because the function is defined multiple times. This resolves the issue by making the zephyr one weak which allows for applications to replace it with an alternative implementation

• Release notes addition

[katgiadla]

it works on-target.

[nashif]

do not like this approach of adding weak symbols so that can be impemented somewhere else. Basically what this mean is an introduction of an adhoc interface or API. We have been trying to minimize the use of weak symbols, because of how unreliable they are when multiple symbols are defined.

[andyross]

No particular complaint about weak symbols, I think they're a fine tool in the right contexts.

But here? I mean, we already allow the banner to be configured. We already allow the banner to be disabled. We already allow apps to register early SYS_INIT() hooks to print their own banners[1] in any way they want.

What's the value in adding another dial to an already complicated whizgig? Who needs this? Frankly I'd argue that the only real value to a banner is that it's "standard" and can be reliably used to identify Zephyr apps across platforms and versions.

Not worth a -1. But I guess maybe I'm saying I'd prefer to see features removed from this area vs. added.

[1] Even before the official one. Ours is actually quite late in the startup sequence; it happens out of the main thread after all the kernel init is already done.

[stephanosio]

MCUboot has had a custom boot banner added which replaces the zephyr one

If so, why would you not just set CONFIG_BOOT_BANNER=n and let MCUboot do its thing?

[nordicjm]

MCUboot has had a custom boot banner added which replaces the zephyr one

If so, why would you not just set CONFIG_BOOT_BANNER=n and let MCUboot do its thing?

If someone wants a boot banner, it makes sense to use a single option, if people have existing applications then updating zephyr would have no impact for them, if they have the boot banner off for their build then nothing will change, adding a new option then means suddenly everyone has it enabled. I don't see the point in having multiple options for the same thing, and what if someone enables them both, the output would just be weird.

do not like this approach of adding weak symbols so that can be impemented somewhere else. Basically what this mean is an introduction of an adhoc interface or API. We have been trying to minimize the use of weak symbols, because of how unreliable they are when multiple symbols are defined.

So would you be opposed to having this defined as an API with a Kconfig to suppress the output so that applications can provide their own function?

[nordicjm]

I have added a banner API and adjusted MCUboot to use this

[andyross]

Still think this is sort of silly, given that a printk() out of a SYS_INIT() hook is absolutely isomorphic to a BOOT_BANNER_EXTERNAL_IMPLEMENTATION.

But no -1, this is obviously harmless. I'm going to remove myself from the bikeshed now. :)

[nashif]

one could also do it without all the changes to zephyr...

diff --git a/samples/hello_world/src/main.c b/samples/hello_world/src/main.c
index c550ab461cb..2effc992235 100644
--- a/samples/hello_world/src/main.c
+++ b/samples/hello_world/src/main.c
@@ -5,6 +5,17 @@
  */

 #include <stdio.h>
+#include <zephyr/kernel.h>
+#include <zephyr/init.h>
+#include <zephyr/device.h>
+
+static int custom_boot_banner(void)
+{
+       printk("*** HELLO WORLD APP BANNER v1.0 ***\n");
+       return 0;
+}
+
+

 int main(void)
 {
@@ -12,3 +23,7 @@ int main(void)

        return 0;
 }
+
+
+
+SYS_INIT(custom_boot_banner, APPLICATION, 0);

resulting in:

*** Booting Zephyr OS build v3.6.99-3532-gd77dc62d196b ***
*** HELLO WORLD APP BANNER v1.0 ***
Hello World! qemu_x86/atom

[henrikbrixandersen]

once could also do it without all the changes to zephyr...

This is pretty much what we do for our downstream applications.

[nordicjm]

once could also do it without all the changes to zephyr...

diff --git a/samples/hello_world/src/main.c b/samples/hello_world/src/main.c
index c550ab461cb..2effc992235 100644
--- a/samples/hello_world/src/main.c
+++ b/samples/hello_world/src/main.c
@@ -5,6 +5,17 @@
  */

 #include <stdio.h>
+#include <zephyr/kernel.h>
+#include <zephyr/init.h>
+#include <zephyr/device.h>
+
+static int custom_boot_banner(void)
+{
+       printk("*** HELLO WORLD APP BANNER v1.0 ***\n");
+       return 0;
+}
+
+

 int main(void)
 {
@@ -12,3 +23,7 @@ int main(void)

        return 0;
 }
+
+
+
+SYS_INIT(custom_boot_banner, APPLICATION, 0);

resulting in:

*** Booting Zephyr OS build v3.6.99-3532-gd77dc62d196b ***
*** HELLO WORLD APP BANNER v1.0 ***
Hello World! qemu_x86/atom

Except that doesn't work for this usecase as mentioned earlier:

If someone wants a boot banner, it makes sense to use a single option, if people have existing applications then updating zephyr would have no impact for them, if they have the boot banner off for their build then nothing will change, adding a new option then means suddenly everyone has it enabled. I don't see the point in having multiple options for the same thing, and what if someone enables them both, the output would just be weird.

[nashif]

Except that doesn't work for this usecase as mentioned earlier:

If someone wants a boot banner, it makes sense to use a single option, if people have existing applications then updating zephyr would have no impact for them, if they have the boot banner off for their build then nothing will change, adding a new option then means suddenly everyone has it enabled. I don't see the point in having multiple options for the same thing, and what if someone enables them both, the output would just be weird.

hmm, I am not sure I understand the usecase here. The code is not adding any options, the app will decide what it wants to print regardless of any options related to boot banner coming from zephyr.

[nordicjm]

Allowing it to be controlled using the same existing Kconfig, e.g.:

menuconfig MCUBOOT_BOOT_BANNER
	bool "Use MCUboot boot banner"
	depends on BOOT_BANNER
	depends on "$(APP_VERSION_EXTENDED_STRING)" != ""
	select BOOT_BANNER_EXTERNAL_IMPLEMENTATION
	default y

Instead of adding a new Kconfig, and this disables the normal boot banner output because it includes a modified version of it in the output:

	    *** Booting MCUboot v2.0.0-72-g8c0e36c88663 ***
	    *** Using Zephyr OS build v3.6.0-2607-gd0be2010c31f ***

You can't have a Kconfig de-select something, so the only way to add another one would be to have depends on !BOOT_BANNER so it can never be active - this is more of an issue when this is used by modules

[nashif]

Allowing it to be controlled using the same existing Kconfig, e.g.:

MCUBOOT_BOOT_BANNER can then control the custom banner you can introduce in mcuboot using something similar to what I have in my example. You do not need to use the zephyr built-in banner

[nordicjm]

Allowing it to be controlled using the same existing Kconfig, e.g.:

MCUBOOT_BOOT_BANNER can then control the custom banner you can introduce in mcuboot using something similar to what I have in my example. You do not need to use the zephyr built-in banner

As said above:

You can't have a Kconfig de-select something, so the only way to add another one would be to have depends on !BOOT_BANNER so it can never be active - this is more of an issue when this is used by modules

And this makes things worse because then everyone out of tree that is using MCUboot that has set CONFIG_BOOT_BANNER=n now suddenly has a new boot banner appear

[carlescufi]

Architecture WG:

• The approach to override boot_banner from the Zephyr has multiple objections
• An alternative approach is proposed, with the use of configdefault for modules that wish to override the Zephyr banner:

In the module's Kconfig file:

configdefault BOOT_BANNER
   default n
   
config MODULE_BOOT_BANNER
   default y
   

CONFIG_BOOT_BANNER=y
*** Booting Zephyr OS build v3.6.0-2607-gd0be2010c31f ***

CONFIG_MODULE_BOOT_BANNER=y
*** Booting Module v2.0.0-72-g8c0e36c88663 ***
if (! CONFIG_BOOT_BANNER)
print *** Using Zephyr OS build v3.6.0-2607-gd0be2010c31f ***
endif

[nashif]

boot_banner should also run when CONFIG_BOOT_BANNER=n to handle the delayed boot option which does not depend on the boot banner.