On 6/20/21 11:49 PM, Michael Ellerman wrote:
> Pass the value of linux_banner to firmware via option vector 7.
>
> Option vector 7 is described in "LoPAR" Linux on Power Architecture
> Reference v2.9, in table B.7 on page 824:
>
> An ASCII character formatted null terminated string that describes
> the client operating system. The string shall be human readable and
> may be displayed on the console.
>
> The string can be up to 256 bytes total, including the nul terminator.
>
> linux_banner contains lots of information, and should make it possible
> to identify the exact kernel version that is running:
>
> const char linux_banner[] =
> "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
> LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
>
> For example:
> Linux version 4.15.0-144-generic (buildd@bos02-ppc64el-018) (gcc
> version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #148-Ubuntu SMP Sat May 8
> 02:32:13 UTC 2021 (Ubuntu 4.15.0-144.148-generic 4.15.18)
>
> It's also printed at boot to the console/dmesg, which should make it
> possible to correlate what firmware receives with the console/dmesg on
> the machine.
>
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>
> ---
>
> NB. linux_banner is already allowed by prom_init_check.sh
>
> LoPAR:
> https://openpowerfoundation.org/?resource_lib=linux-on-power-architecture-reference-a-papr-linux-subset-review-draft
> ---
> arch/powerpc/kernel/prom_init.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index c18d55f8b951..7343076b261c 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -27,6 +27,7 @@
> #include <linux/initrd.h>
> #include <linux/bitops.h>
> #include <linux/pgtable.h>
> +#include <linux/printk.h>
> #include <asm/prom.h>
> #include <asm/rtas.h>
> #include <asm/page.h>
> @@ -944,6 +945,10 @@ struct option_vector6 {
> u8 os_name;
> } __packed;
>
> +struct option_vector7 {
> + u8 os_id[256];
> +} __packed;
> +
> struct ibm_arch_vec {
> struct { u32 mask, val; } pvrs[14];
>
> @@ -966,6 +971,9 @@ struct ibm_arch_vec {
>
> u8 vec6_len;
> struct option_vector6 vec6;
> +
> + u8 vec7_len;
> + struct option_vector7 vec7;
> } __packed;
>
> static const struct ibm_arch_vec ibm_architecture_vec_template __initconst =
> {
> @@ -1112,6 +1120,9 @@ static const struct ibm_arch_vec
> ibm_architecture_vec_template __initconst = {
> .secondary_pteg = 0,
> .os_name = OV6_LINUX,
> },
> +
> + /* option vector 7: OS Identification */
> + .vec7_len = VECTOR_LENGTH(sizeof(struct option_vector7)),
> };
>
> static struct ibm_arch_vec __prombss ibm_architecture_vec
> ____cacheline_aligned;
> @@ -1340,6 +1351,10 @@ static void __init prom_check_platform_support(void)
> memcpy(&ibm_architecture_vec, &ibm_architecture_vec_template,
> sizeof(ibm_architecture_vec));
>
> + prom_strscpy_pad(ibm_architecture_vec.vec7.os_id, linux_banner, 256);
> + // Ensure nul termination
> + ibm_architecture_vec.vec7.os_id[255] = '\0';
> +
Doesn't the implementation of prom_strscpy_pad() in patch 1 ensure nul
termination?
-Tyrel
> if (prop_len > 1) {
> int i;
> u8 vec[8];
>
