u-boot.git/common/Kconfig, branch v2023.01

vpl: Allow signature verification

2022-10-31T15:04:00Z

Add the required Kconfig option so that signatures can be verified when loading a configuration. Signed-off-by: Simon Glass

spl: Add a separate silence option for SPL

2022-10-31T15:01:31Z

Add an option to allow silent console to be controlled separately in SPL, so that boot progress can be shown. Disable it by default for sandbox since it is useful to see what is going on there. Signed-off-by: Simon Glass

video: Rename CONFIG_DM_VIDEO to CONFIG_VIDEO

2022-10-30T19:07:17Z

Now that all the old code is gone, rename this option. Driver model migration is now complete. Signed-off-by: Simon Glass

event: Fix a typo in the EVENT help

2022-09-29T20:07:57Z

Fix the help message. Signed-off-by: Simon Glass

console: Implement flush() function

2022-09-24T14:47:01Z

On certain places it is required to flush output print buffers to ensure that text strings were sent to console or serial devices. For example when printing message that U-Boot is going to boot kernel or when U-Boot is going to change baudrate of terminal device. Therefore introduce a new flush() and fflush() functions into console code. These functions will call .flush callback of associated stdio_dev device. As this function may increase U-Boot side, allow to compile U-Boot without this function. For this purpose there is a new config CONSOLE_FLUSH_SUPPORT which is enabled by default and can be disabled. It is a good idea to have this option enabled for all boards which have enough space for it. When option is disabled when U-Boot defines just empty static inline function fflush() to avoid ifdefs in other code. Signed-off-by: Pali Rohár Reviewed-by: Simon Glass

Merge branch 'master' into next

2022-09-19T20:07:12Z

Signed-off-by: Tom Rini

cyclic: Add basic support for cyclic function execution infrastruture

2022-09-13T20:01:43Z

Add the basic infrastructure to periodically execute code, e.g. all 100ms. Examples for such functions might be LED blinking etc. The functions that are hooked into this cyclic list should be small timewise as otherwise the execution of the other code that relies on a high frequent polling (e.g. UART rx char ready check) might be delayed too much. This patch also adds the Kconfig option CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time for such a cyclic function. If it's execution time exceeds this time, this cyclic function will get removed from the cyclic list. How is this cyclic functionality executed? The following patch integrates the main function responsible for calling all registered cyclic functions cyclic_run() into the common WATCHDOG_RESET macro. This guarantees that cyclic_run() is executed very often, which is necessary for the cyclic functions to get scheduled and executed at their configured periods. This cyclic infrastructure will be used by a board specific function on the NIC23 MIPS Octeon board, which needs to check periodically, if a PCIe FLR has occurred. Signed-off-by: Stefan Roese Reviewed-by: Simon Glass

fdt_support: add optional board_rng_seed() hook

2022-09-12T12:41:14Z

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

Convert CONFIG_SYS_I2C_EEPROM_CCID et al to Kconfig

2022-09-01T21:18:42Z

This converts the following to Kconfig: CONFIG_SYS_I2C_EEPROM_CCID CONFIG_SYS_I2C_EEPROM_NXID CONFIG_SYS_EEPROM_BUS_NUM Signed-off-by: Tom Rini

spl: Ensure all SPL symbols in Kconfig have some SPL dependency

2022-07-07T13:29:08Z

Tighten up symbol dependencies in a number of places. Ensure that a SPL specific option has at least a direct dependency on SPL. In places where it's clear that we depend on something more specific, use that dependency instead. This means in a very small number of places we can drop redundant dependencies. Reported-by: Pali Rohár Signed-off-by: Tom Rini