u-boot.git/common, branch v2022.10 Unnamed repository; edit this file 'description' to name the repository. board_r: Relocate OF_EMBED if NEEDS_MANUAL_RELOC only 2022-09-29T14:10:39+00:00 Pierre-Clément Tosi ptosi@google.com 2022-09-09T20:16:18+00:00 76f921eb95d5b814f973a263187db509d6f03903 When the embedded device tree is pointed to by the __dtb_dt_*begin symbols, it seems to be covered by the early relocation code and doesn't need to be manually patched. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Pierre-Clément Tosi <ptosi@google.com> 
When the embedded device tree is pointed to by the __dtb_dt_*begin
symbols, it seems to be covered by the early relocation code and doesn't
need to be manually patched.

Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
autoboot: make sure watchdog device(s) are handled with keyed autoboot 2022-09-27T10:25:51+00:00 Rasmus Villemoes rasmus.villemoes@prevas.dk 2022-09-27T09:54:02+00:00 c11cedc876631c1753427a68db4efaa00f700a79 Currently, AUTOBOOT_KEYED and its variant AUTOBOOT_ENCRYPTION are broken when one has an external always-running watchdog device with a timeout shorter than the configured boot delay (in my case, I have a gpio-wdt one with a timeout of 1 second), because we fail to call WATCHDOG_RESET() in the loops where we wait for the bootdelay to elapse. This is done implicitly in the !AUTOBOOT_KEYED case, i.e. abortboot_single_key(), because that loop contains a udelay(10000), and udelay() does a WATCHDOG_RESET(). To fix this, simply add similar udelay() calls in the other loops. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Stefan Roese <sr@denx.de> 
Currently, AUTOBOOT_KEYED and its variant AUTOBOOT_ENCRYPTION are
broken when one has an external always-running watchdog device with a
timeout shorter than the configured boot delay (in my case, I have a
gpio-wdt one with a timeout of 1 second), because we fail to call
WATCHDOG_RESET() in the loops where we wait for the bootdelay to
elapse.

This is done implicitly in the !AUTOBOOT_KEYED case,
i.e. abortboot_single_key(), because that loop contains a
udelay(10000), and udelay() does a WATCHDOG_RESET().

To fix this, simply add similar udelay() calls in the other loops.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Stefan Roese <sr@denx.de>
fdt_support: add optional board_rng_seed() hook 2022-09-12T12:41:14+00:00 Rasmus Villemoes rasmus.villemoes@prevas.dk 2022-08-22T07:34:23+00:00 6dca1d9ad38de9b7f9a44d2c6eaa6acf9be6c2c0 A recurring theme on LKML is the boot process deadlocking due to some process blocking waiting for random numbers, while the kernel's Cryptographic Random Number Generator (crng) is not initalized yet, but that very blocking means no activity happens that would generate the entropy necessary to finalize seeding the crng. This is not a problem on boards that have a good hwrng (when the kernel is configured to trust it), whether in the CPU or in a TPM or elsewhere. However, that's far from all boards out there. Moreover, there are consumers in the kernel that try to obtain random numbers very early, before the kernel has had any chance to initialize any hwrng or other peripherals. Allow a board to provide a board_rng_seed() function, which is responsible for providing a value to be put into the rng-seed property under the /chosen node. The board code is responsible for how to actually obtain those bytes. - One possibility is for the board to load a seed "file" from somewhere (it need not be a file in a filesystem of course), and then ensure that that the same seed file does not get used on subsequent boots. * One way to do that is to delete the file, or otherwise mark it as invalid, then rely on userspace to create a new one, and living with the possibility of not finding a seed file during some boots. * Another is to use the scheme used by systemd-boot and create a new seed file immediately, but in a way that the seed passed to the kernel and the new (i.e. next) seed cannot be deduced from each other, see the explanation at https://lore.kernel.org/lkml/20190929090512.GB13049@gardel-login/ and the current code at https://github.com/systemd/systemd/blob/main/src/boot/efi/random-seed.c - The board may have an hwrng from which some bytes can be read; while the kernel can also do that, doing it in U-Boot and providing a seed ensures that even very early users in the kernel get good random numbers. - If the board has a sensor of some sort (temperature, humidity, GPS, RTC, whatever), mixing in a reading of that doesn't hurt. - etc. etc. These can of course be combined. The rng-seed property is mixed into the pool used by the linux kernel's CRNG very early during boot. Whether it then actually contributes towards the kernel considering the CRNG initialized depends on whether the kernel has been configured with CONFIG_RANDOM_TRUST_BOOTLOADER (nowadays overridable via the random.trust_bootloader command line option). But that's for the BSP developer to ultimately decide. So, if the board needs to have all that logic, why not also just have it do the actual population of /chosen/rng-seed in ft_board_setup(), which is not that many extra lines of code? I considered that, but decided handling this logically belongs in fdt_chosen(). Also, apart from saving the board code from the few lines of boilerplate, doing it in ft_board_setup() is too late for at least some use cases. For example, I want to allow the board logic to decide ok, let's pass back this buffer and use that as seed, but also let's set random.trust_bootloader=n so no entropy is credited. This requires the rng-seed handling to happen before bootargs handling. For example, during the very first boot, the board might not have a proper seed file, but the board could still return (a hash of) some CPU serial# or whatnot, so that at least no two boards ever get the same seed - the kernel always mixes in the value passed in rng-seed, but if it is not "trusted", the kernel would still go through the same motions as it would if no rng-seed was passed before considering its CRNG initialized. I.e., by returning that unique-to-this-board value and setting random.trust_bootloader=n, the board would be no worse off than if board_rng_seed() returned nothing at all. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> 
A recurring theme on LKML is the boot process deadlocking due to some
process blocking waiting for random numbers, while the kernel's
Cryptographic Random Number Generator (crng) is not initalized yet,
but that very blocking means no activity happens that would generate
the entropy necessary to finalize seeding the crng.

This is not a problem on boards that have a good hwrng (when the
kernel is configured to trust it), whether in the CPU or in a TPM or
elsewhere. However, that's far from all boards out there. Moreover,
there are consumers in the kernel that try to obtain random numbers
very early, before the kernel has had any chance to initialize any
hwrng or other peripherals.

Allow a board to provide a board_rng_seed() function, which is
responsible for providing a value to be put into the rng-seed property
under the /chosen node.

The board code is responsible for how to actually obtain those
bytes.

- One possibility is for the board to load a seed "file" from
  somewhere (it need not be a file in a filesystem of course), and
  then ensure that that the same seed file does not get used on
  subsequent boots.

  * One way to do that is to delete the file, or otherwise mark it as
    invalid, then rely on userspace to create a new one, and living
    with the possibility of not finding a seed file during some boots.

  * Another is to use the scheme used by systemd-boot and create a new
    seed file immediately, but in a way that the seed passed to the
    kernel and the new (i.e. next) seed cannot be deduced from each
    other, see the explanation at
    https://lore.kernel.org/lkml/20190929090512.GB13049@gardel-login/
    and the current code at
    https://github.com/systemd/systemd/blob/main/src/boot/efi/random-seed.c

- The board may have an hwrng from which some bytes can be read; while
  the kernel can also do that, doing it in U-Boot and providing a seed
  ensures that even very early users in the kernel get good random
  numbers.

- If the board has a sensor of some sort (temperature, humidity, GPS,
  RTC, whatever), mixing in a reading of that doesn't hurt.

- etc. etc.

These can of course be combined.

The rng-seed property is mixed into the pool used by the linux
kernel's CRNG very early during boot. Whether it then actually
contributes towards the kernel considering the CRNG initialized
depends on whether the kernel has been configured with
CONFIG_RANDOM_TRUST_BOOTLOADER (nowadays overridable via the
random.trust_bootloader command line option). But that's for the BSP
developer to ultimately decide.

So, if the board needs to have all that logic, why not also just have
it do the actual population of /chosen/rng-seed in ft_board_setup(),
which is not that many extra lines of code?

I considered that, but decided handling this logically belongs in
fdt_chosen(). Also, apart from saving the board code from the few
lines of boilerplate, doing it in ft_board_setup() is too late for at
least some use cases. For example, I want to allow the board logic to
decide

  ok, let's pass back this buffer and use that as seed, but also let's
  set random.trust_bootloader=n so no entropy is credited.

This requires the rng-seed handling to happen before bootargs
handling. For example, during the very first boot, the board might not
have a proper seed file, but the board could still return (a hash of)
some CPU serial# or whatnot, so that at least no two boards ever get
the same seed - the kernel always mixes in the value passed in
rng-seed, but if it is not "trusted", the kernel would still go
through the same motions as it would if no rng-seed was passed before
considering its CRNG initialized. I.e., by returning that
unique-to-this-board value and setting random.trust_bootloader=n, the
board would be no worse off than if board_rng_seed() returned nothing
at all.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
common/console.c: prevent pre-console buffer contents from being added to itself 2022-08-31T16:16:01+00:00 Rasmus Villemoes rasmus.villemoes@prevas.dk 2022-05-03T13:13:27+00:00 04a20ca5dc9f9eb8929097ff0c93cfe905bc7191 I do not have any non-serial output devices, so a print_pre_console_buffer(PRE_CONSOLE_FLUSHPOINT2_EVERYTHING_BUT_SERIAL) does nothing for me. However, I was manually inspected the pre-console buffer using md.b, and I noticed that the early part of it was repeated. The reason is that the first call of print_pre_console_buffer(), from console_init_f(), ends up invoking puts() with the contents of the buffer at that point, and puts() at that point ends up in the else branch of if (gd->flags & GD_FLG_DEVINIT) { /* Send to the standard output */ fputs(stdout, s); } else { /* Send directly to the handler */ pre_console_puts(s); serial_puts(s); } so indeed the contents is added again. That can be somewhat confusing (both when reading the buffer manually, but also if it did actually come out on some device). So disable all use of the pre-console buffer while print_pre_console_buffer() is emitting it. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org> 
I do not have any non-serial output devices, so a
print_pre_console_buffer(PRE_CONSOLE_FLUSHPOINT2_EVERYTHING_BUT_SERIAL)
does nothing for me.

However, I was manually inspected the pre-console buffer using md.b,
and I noticed that the early part of it was repeated. The reason is
that the first call of print_pre_console_buffer(), from
console_init_f(), ends up invoking puts() with the contents of the
buffer at that point, and puts() at that point ends up in the else
branch of

	if (gd->flags & GD_FLG_DEVINIT) {
		/* Send to the standard output */
		fputs(stdout, s);
	} else {
		/* Send directly to the handler */
		pre_console_puts(s);
		serial_puts(s);
	}

so indeed the contents is added again.

That can be somewhat confusing (both when reading the buffer manually,
but also if it did actually come out on some device). So disable all
use of the pre-console buffer while print_pre_console_buffer() is
emitting it.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
bootstage: Show func name for bootstage_mark/error 2022-08-21T00:07:32+00:00 Michal Simek michal.simek@amd.com 2022-08-12T08:54:51+00:00 55bc22760c362bba478d449ea7ba59667c4eefe4 bootstage_mark() and bootstate_error() are not recording any name and in report it is showing as id=<value>. That's not useful and it is better to show function name which calls it. That's why use macros with passing __func__ as recorded name for bootstage. Origin report looks like this: ZynqMP> bootstage report Timer summary in microseconds (10 records): Mark Elapsed Stage 0 0 reset 2,482,383 2,482,383 board_init_f 4,278,821 1,796,438 board_init_r 4,825,331 546,510 id=64 4,858,409 33,078 id=65 4,862,382 3,973 main_loop 4,921,713 59,331 usb_start 9,345,345 4,423,632 id=175 When this patch is applied. ZynqMP> bootstage report Timer summary in microseconds (31 records): Mark Elapsed Stage 0 0 reset 2,465,624 2,465,624 board_init_f 4,278,628 1,813,004 board_init_r 4,825,139 546,511 eth_common_init 4,858,228 33,089 eth_initialize 4,862,201 3,973 main_loop 4,921,530 59,329 usb_start 8,885,334 3,963,804 cli_loop Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
bootstage_mark() and bootstate_error() are not recording any name and in
report it is showing as id=<value>. That's not useful and it is better to
show function name which calls it.
That's why use macros with passing __func__ as recorded name for bootstage.

Origin report looks like this:
ZynqMP> bootstage report
Timer summary in microseconds (10 records):
       Mark    Elapsed  Stage
          0          0  reset
  2,482,383  2,482,383  board_init_f
  4,278,821  1,796,438  board_init_r
  4,825,331    546,510  id=64
  4,858,409     33,078  id=65
  4,862,382      3,973  main_loop
  4,921,713     59,331  usb_start
  9,345,345  4,423,632  id=175

When this patch is applied.
ZynqMP> bootstage report
Timer summary in microseconds (31 records):
       Mark    Elapsed  Stage
          0          0  reset
  2,465,624  2,465,624  board_init_f
  4,278,628  1,813,004  board_init_r
  4,825,139    546,511  eth_common_init
  4,858,228     33,089  eth_initialize
  4,862,201      3,973  main_loop
  4,921,530     59,329  usb_start
  8,885,334  3,963,804  cli_loop

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
hwconfig: Allow to use restricted env 2022-08-20T22:12:51+00:00 Pali Rohár pali@kernel.org 2022-08-07T19:06:04+00:00 a871af2d5a59c26d4ff7e60530a7afce0742e6f0 During early boot phase GD_FLG_ENV_READY is not set but env_get() may work when env is ready in restricted mode. Do not fail with error message "WARNING: Calling __hwconfig without a buffer and before environment is ready" when env is already working by checking for ENV_VALID flag. Signed-off-by: Pali Rohár <pali@kernel.org> 
During early boot phase GD_FLG_ENV_READY is not set but env_get() may work
when env is ready in restricted mode. Do not fail with error message
"WARNING: Calling __hwconfig without a buffer and before environment is ready"
when env is already working by checking for ENV_VALID flag.

Signed-off-by: Pali Rohár <pali@kernel.org>
event: Add an event for device tree fixups 2022-08-12T12:17:11+00:00 Simon Glass sjg@chromium.org 2022-07-30T21:52:31+00:00 98887ab802e4118e7c813e5e052678772fa1b3a8 At present there is a confusing array of functions that handle the device tree fix-ups needed for booting an OS. We should be able to switch to using events to clean this up. As a first step, create a new event type and call it from the standard place. Note that this event uses the ofnode interface only, since this can support live tree which is more efficient when making lots of updates. Signed-off-by: Simon Glass <sjg@chromium.org> 
At present there is a confusing array of functions that handle the
device tree fix-ups needed for booting an OS. We should be able to switch
to using events to clean this up.

As a first step, create a new event type and call it from the standard
place.

Note that this event uses the ofnode interface only, since this can
support live tree which is more efficient when making lots of updates.

Signed-off-by: Simon Glass <sjg@chromium.org>
spl: opensbi: convert scratch options to config 2022-08-11T10:46:41+00:00 Nikita Shubin n.shubin@yadro.com 2022-08-08T10:28:52+00:00 aa0eda17cf98448c3ef826204f38c76bf48b3345 Convert hardcoded "opensbi_info.options" to config provided value, this allows changing options passed to OpenSBI. SPL_OPENSBI_SCRATCH_OPTIONS is defaulted to SBI_SCRATCH_NO_BOOT_PRINTS. Link: https://github.com/riscv-software-src/opensbi/blob/master/docs/firmware/fw_dynamic.md Signed-off-by: Nikita Shubin <n.shubin@yadro.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com> 
Convert hardcoded "opensbi_info.options" to config provided value, this
allows changing options passed to OpenSBI.

SPL_OPENSBI_SCRATCH_OPTIONS is defaulted to SBI_SCRATCH_NO_BOOT_PRINTS.

Link: https://github.com/riscv-software-src/opensbi/blob/master/docs/firmware/fw_dynamic.md
Signed-off-by: Nikita Shubin <n.shubin@yadro.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
spl: opensbi: fix typo 2022-08-11T10:46:37+00:00 Nikita Shubin n.shubin@yadro.com 2022-08-08T10:24:25+00:00 48da0ca16eb3f31f54373e126eb63e18eb4d828f s/obensbi_info/opensbi_info/ Signed-off-by: Nikita Shubin <n.shubin@yadro.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com> 
s/obensbi_info/opensbi_info/

Signed-off-by: Nikita Shubin <n.shubin@yadro.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
common: Drop display_options.h from common header 2022-08-10T17:46:55+00:00 Simon Glass sjg@chromium.org 2022-07-31T18:28:48+00:00 4e4bf9449b4f436419490a4a8cf4de17433cac15 Move this out of the common header and include it only where needed. Signed-off-by: Simon Glass <sjg@chromium.org> 
Move this out of the common header and include it only where needed.

Signed-off-by: Simon Glass <sjg@chromium.org>