[Letux-kernel] X1600 / LX16 support - here: fw_getenv() issue

H. Nikolaus Schaller hns at goldelico.com
Tue Feb 6 22:38:08 CET 2024


Hi all,

> Am 06.02.2024 um 20:20 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi all,
> 
>> Am 06.02.2024 um 19:24 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
> All this does not fit to copying fw_arg2 to _fw_envp in fw_init_cmdline()
> and starting to scan at index 0 in fw_getenv().
> 
> Here is a hint on what U-Boot bootm is doing:
> 
> https://docs.u-boot.org/en/stable/usage/cmd/bootm.html?highlight=bootm
> 
> If I read correctly there are two different formats. And, the second parameter
> is NOT a list of some environment variables but the start address of a RAMDISK?
> 
> But what is then the story behind fw_getenv() at all?
> 
> And U-Boot starts the kernel by
> 
> bootcmd=fatload mmc 0 0x80a00000 /uImage; bootm 0x80a00000
> 
> I.e. there is no second parameter???

I just realized that this all fw_getenv() is MIPS specific! No other architecture
or driver uses this.

arch/mips/fw/lib/cmdline.c:char *fw_getenv(char *envname)

So I am not sure if this needs some patch in U-Boot to do what is expected.
And I do not exactly know what is expected :)

Some MIPS processors seem to use fw_getenv() to look for "initrd_start", "fdt_start",
"yamontty", "cpuclock", "memsize", "modetty0".

And because I grepped this on the 5.10 kernel, I found the answer why it works
on 5.10 but not with 6.8:

In 5.10.y fw_getenv() isn't called at all... Hence it is no problem that it would fail.

There is simply no setup_rng_seed() calling fw_getenv("rngseed"):

https://elixir.bootlin.com/linux/v6.8-rc3/source/arch/mips/kernel/setup.c#L760
https://elixir.bootlin.com/linux/v5.10.209/source/arch/mips/kernel/setup.c#L765

It was easy to ask git blame where this was introduced...

commit 056a68cea01edfa78b3474af1bfa39cc6bcc7bee
Author: Jason A. Donenfeld <Jason at zx2c4.com>
Date:   Fri Sep 30 16:01:38 2022 +0200

    mips: allow firmware to pass RNG seed to kernel
         Nearly all other firmware environments have some way of passing a RNG
    seed to initialize the RNG: DTB's rng-seed, EFI's RNG protocol, m68k's
    bootinfo block, x86's setup_data, and so forth. This adds something
    similar for MIPS, which will allow various firmware environments,
    bootloaders, and hypervisors to pass an RNG seed to initialize the
    kernel's RNG.
         Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend at alpha.franken.de>

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 2ca156a5b2319..39c79f67c7a33 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -42,6 +42,7 @@
 #include <asm/setup.h>
 #include <asm/smp-ops.h>
 #include <asm/prom.h>
+#include <asm/fw/fw.h>
   #ifdef CONFIG_MIPS_ELF_APPENDED_DTB
 char __section(".appended_dtb") __appended_dtb[0x100000];
@@ -756,6 +757,24 @@ static void __init prefill_possible_map(void)
 static inline void prefill_possible_map(void) {}
 #endif
  +static void __init setup_rng_seed(void)
+{
+       char *rng_seed_hex = fw_getenv("rngseed");
+       u8 rng_seed[512];
+       size_t len;
+
+       if (!rng_seed_hex)
+               return;
+
+       len = min(sizeof(rng_seed), strlen(rng_seed_hex) / 2);
+       if (hex2bin(rng_seed, rng_seed_hex, len))
+               return;
+
+       add_bootloader_randomness(rng_seed, len);
+       memzero_explicit(rng_seed, len);
+       memzero_explicit(rng_seed_hex, len * 2);
+}
+
 void __init setup_arch(char **cmdline_p)
 {
        cpu_probe();
@@ -786,6 +805,8 @@ void __init setup_arch(char **cmdline_p)
        paging_init();
          memblock_dump_all();
+
+       setup_rng_seed();
 }
   unsigned long kernelsp[NR_CPUS];


Now the question is how to fix it:
a) in kernel (may be difficult and not upstreamable - or it should get a CONFIG option)
b) in U-Boot (may also be difficult)

So we have to research what the MIPS specific "firmware environment" is
where a pointer is passed in a register to fw_arg2.

BR,
Nikolaus



More information about the Letux-kernel mailing list