u-boot.git/common/main.c, branch master Unnamed repository; edit this file 'description' to name the repository. Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet" 2024-05-20T19:35:03+00:00 Tom Rini trini@konsulko.com 2024-05-20T19:35:03+00:00 03de305ec48b0bb28554372abb40ccd46dbe0bf9 As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" 2024-05-19T14:16:36+00:00 Tom Rini trini@konsulko.com 2024-05-19T02:20:43+00:00 d678a59d2d719da9e807495b4b021501f2836ca5 When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
common: Remove <common.h> and add needed includes 2024-05-06T21:05:04+00:00 Tom Rini trini@konsulko.com 2024-04-27T14:11:00+00:00 a79fc7a79cc9d4f7a46b19a4891484ac1e9ef599 Remove <common.h> from all "commmon/" files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com> 
Remove <common.h> from all "commmon/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>
boot: add support for button commands 2024-02-13T20:38:49+00:00 Caleb Connolly caleb.connolly@linaro.org 2024-01-09T11:51:09+00:00 e761035b64235db8930eb15d2703dc3f43e99224 With the relatively new button API in U-Boot, it's now much easier to model the common usecase of mapping arbitrary actions to different buttons during boot - for example entering fastboot mode, setting some additional kernel cmdline arguments, or booting with a custom recovery ramdisk, to name a few. Historically, this functionality has been implemented in board code, making it fixed for a given U-Boot binary and requiring the code be duplicated and modified for every board. Implement a generic abstraction to run an arbitrary command during boot when a specific button is pressed. The button -> command mapping is configured via environment variables with the following format: button_cmd_N_name=<button label> button_cmd_N=<command to run> Where N is the mapping number starting from 0. For example: button_cmd_0_name=vol_down button_cmd_0=fastboot usb 0 This will cause the device to enter fastboot mode if volume down is held during boot. After we enter the cli loop the button commands are no longer valid, this allows the buttons to additionally be used for navigating a boot menu. Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Tegra30 Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> 
With the relatively new button API in U-Boot, it's now much easier to
model the common usecase of mapping arbitrary actions to different
buttons during boot - for example entering fastboot mode, setting some
additional kernel cmdline arguments, or booting with a custom recovery
ramdisk, to name a few.

Historically, this functionality has been implemented in board code,
making it fixed for a given U-Boot binary and requiring the code be
duplicated and modified for every board.

Implement a generic abstraction to run an arbitrary command during boot
when a specific button is pressed. The button -> command mapping is
configured via environment variables with the following format:

  button_cmd_N_name=<button label>
  button_cmd_N=<command to run>

Where N is the mapping number starting from 0. For example:

  button_cmd_0_name=vol_down
  button_cmd_0=fastboot usb 0

This will cause the device to enter fastboot mode if volume down is held
during boot.

After we enter the cli loop the button commands are no longer valid,
this allows the buttons to additionally be used for navigating a boot
menu.

Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Tegra30
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
bootstd: Introduce programmatic boot 2023-12-13T16:51:24+00:00 Simon Glass sjg@chromium.org 2023-11-18T21:05:19+00:00 1047b5340c1203f825c0a68b33997b787be0123e At present bootstd requires CONFIG_CMDLINE to operate. Add a new 'programmatic' boot which can be used when no command line is available. For now it does almost nothing, since most bootmeths require the command line. Signed-off-by: Simon Glass <sjg@chromium.org> 
At present bootstd requires CONFIG_CMDLINE to operate. Add a new
'programmatic' boot which can be used when no command line is available.
For now it does almost nothing, since most bootmeths require the
command line.

Signed-off-by: Simon Glass <sjg@chromium.org>
binman: add sign option for binman 2023-03-14T22:08:51+00:00 Ivan Mikhaylov fr0st61te@gmail.com 2023-03-08T01:13:39+00:00 4023dc9c95ccb5bcb3719c1c10e3d4dce967e0a2 Introduce proof of concept for binman's new option which provides sign and replace FIT containers in binary images. Usage as example: from: mkimage -G privateky -r -o sha256,rsa4096 -F fit binman replace -i flash.bin -f fit.fit fit to: binman sign -i flash.bin -k privatekey -a sha256,rsa4096 -f fit.fit fit and to this one if it's need to be extracted, signed with key and put it back in image: binman sign -i flash.bin -k privatekey -a sha256,rsa4096 fit Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com> 
Introduce proof of concept for binman's new option which provides sign
and replace FIT containers in binary images.

Usage as example:

from:
mkimage -G privateky -r -o sha256,rsa4096 -F fit
binman replace -i flash.bin -f fit.fit fit

to:
binman sign -i flash.bin -k privatekey -a sha256,rsa4096 -f fit.fit fit

and to this one if it's need to be extracted, signed with key and put it
back in image:
binman sign -i flash.bin -k privatekey -a sha256,rsa4096 fit

Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
efi_loader: split efi_init_obj_list() into two stages 2022-04-23T20:05:41+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-04-19T01:05:11+00:00 a57ad20d07e82f9ddbbdf981c8f8dd5368b225e4 In the next commit, CONFIG_EFI_SETUP_EARLY will become mandated in order to support dynamic enumeration of efi_disk objects. This can, however, be problematic particularly in case of file-based variable storage (efi_variable.c, default). Non-volatile variables are to be restored from EFI system partition by efi_init_variables() in efi_init_obj_list(). When efi_init_obj_list() is called in board_init_r(), we don't know yet what disk devices we have since none of device probing commands (say, scsi rescan) has not been executed at that stage. So in this commit, a preparatory change is made; efi_init_obj_list() is broken into the two functions; * efi_init_early(), and * new efi_init_obj_list() Only efi_init_early() will be called in board_init_r(), which allows us to execute any of device probing commands, either though "preboot" variable or normal command line, before calling efi_init_obj_list() which is to be invoked at the first execution of an efi-related command (or at efi_launch_capsules()) as used to be. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> 
In the next commit, CONFIG_EFI_SETUP_EARLY will become mandated
in order to support dynamic enumeration of efi_disk objects.

This can, however, be problematic particularly in case of file-based
variable storage (efi_variable.c, default).
Non-volatile variables are to be restored from EFI system partition
by efi_init_variables() in efi_init_obj_list(). When efi_init_obj_list()
is called in board_init_r(), we don't know yet what disk devices
we have since none of device probing commands (say, scsi rescan) has not
been executed at that stage.

So in this commit, a preparatory change is made; efi_init_obj_list() is
broken into the two functions;
   * efi_init_early(), and
   * new efi_init_obj_list()

Only efi_init_early() will be called in board_init_r(), which allows
us to execute any of device probing commands, either though "preboot"
variable or normal command line, before calling efi_init_obj_list() which
is to be invoked at the first execution of an efi-related command
(or at efi_launch_capsules()) as used to be.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
version: Move version_string[] from version.h to version_string.h 2021-09-17T16:10:44+00:00 Pali Rohár pali@kernel.org 2021-08-02T13:18:31+00:00 bdfb6d70bb45da6e31785171fed70cb93b0ff36b More C files do not use compile time timestamp macros and do not have to be recompiled every time when SOURCE_DATE_EPOCH changes. This patch moves version_string[] from version.h to version_string.h and updates other C files which only needs version_string[] string to include version_string.h instead of version.h. After applying this patch these files are not recompiled every time when SOURCE_DATE_EPOCH changes. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Tom Rini <trini@konsulko.com> 
More C files do not use compile time timestamp macros and do not have to be
recompiled every time when SOURCE_DATE_EPOCH changes.

This patch moves version_string[] from version.h to version_string.h and
updates other C files which only needs version_string[] string to include
version_string.h instead of version.h. After applying this patch these
files are not recompiled every time when SOURCE_DATE_EPOCH changes.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
efi_loader: capsule: add capsule_on_disk support 2020-12-03T20:22:49+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2020-11-17T00:27:56+00:00 c74cd8bd08d1bbff366a1bfb0cc82a2413fdf106 Capsule data can be loaded into the system either via UpdateCapsule runtime service or files on a file system (of boot device). The latter case is called "capsules on disk", and actual updates will take place at the next boot time. In this commit, we will support capsule on disk mechanism. Please note that U-Boot itself has no notion of "boot device" and all the capsule files to be executed will be detected only if they are located in a specific directory, \EFI\UpdateCapsule, on a device that is identified as a boot device by "BootXXXX" variables. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> 
Capsule data can be loaded into the system either via UpdateCapsule
runtime service or files on a file system (of boot device).
The latter case is called "capsules on disk", and actual updates will
take place at the next boot time.

In this commit, we will support capsule on disk mechanism.

Please note that U-Boot itself has no notion of "boot device" and
all the capsule files to be executed will be detected only if they
are located in a specific directory, \EFI\UpdateCapsule, on a device
that is identified as a boot device by "BootXXXX" variables.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
common: Drop bootstage.h from common header 2020-05-18T21:33:33+00:00 Simon Glass sjg@chromium.org 2020-05-10T17:40:00+00:00 52f24238046ca28085f6de946d0358e5c7c7cbe8 Move this fairly uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org> 
Move this fairly uncommon header out of the common header.

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