Add a new 'bootstd images' command, which lists the images which have been loaded. Update some existing tests to use it. Provide some documentation about images in general and this command in particular. Use a more realistic kernel command-line to make the test easier to follow. Signed-off-by: Simon Glass <sjg@chromium.org>
As a first step to recording images and where they came from, update this function to do so, since it is used by two bootmeths Create a helper function in the bootflow system, since recorded images are always associated with bootflows. Signed-off-by: Simon Glass <sjg@chromium.org>
We want to keep track of images which are loaded, or those which could perhaps be loaded. This will make it easier to manage memory allocation, as well as permit removal of the EFI set_efi_bootdev() feature. Add a list of these, attached to the bootflow. For now the list is empty. Signed-off-by: Simon Glass <sjg@chromium.org>
Use an alist for this data structure as it is somewhat simpler to manage. This means that bootstd holds a simple list of bootflow structs and can drop it at will, without chasing down lists. Signed-off-by: Simon Glass <sjg@chromium.org>
This list is only used by two functions, which can be updated to iterate through the global list. Take this approach, which allows the bootdev list to be dropped. Overall this makes the code slightly more complicated, but will allow moving the bootflow list into an alist Signed-off-by: Simon Glass <sjg@chromium.org>
Some bootflows might be able to only boot from MMC devices. Add a helper function these bootflows can use. Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com> Reviewed-by: Julien Masson <jmasson@baylibre.com> Reviewed-by: Guillaume La Roque <glaroque@baylibre.com> Tested-by: Guillaume La Roque <glaroque@baylibre.com> Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org>
The global bootmeths don't set the dev in bootflow struct which means the dev_get_parent(bflow->dev) triggers a NULL-pointer dereference and crash U-Boot. So before trying to handle a bootflow, check that the associated bootmeth isn't global, otherwise skip it. Suggested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
The "bootflow" command currently doesn't support scanning a single partition. This is inconvenient in setups with multiple bootable partitions within a single disk, but only one is desired. Support scanning a single disk partition. Specifically, support the syntax: bootflow scan mmc1:4 which scans only mmc device 1, partition 4. Signed-off-by: Nam Cao <namcao@linutronix.de>
While booting with efi, if fdt isn't available externally, just use the built-in one. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Shantur Rathore <i@shantur.com>
EFI applications can be very large and thus used to cause boot failures when malloc() space was exhausted. A recent changed fixed this by using the kernel_addr_r environment var as the address of the buffer. However, it still frees the buffer when the bootflow is discarded. Fix this by introducing a flag to indicate whether the buffer was allocated, or not. Note that kernel_addr_r is not the last word here. It might be better to use lmb to place images. But there is a lot of refactoring to do before we can remove the environment variables. The distro scripts rely on them so it is safe for bootstd to do so too. Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file Signed-off-by: Simon Glass <sjg@chromium.org> Reported by: Simon Glass <sjg@chromium.org> Reported by: Shantur Rathore <i@shantur.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Shantur Rathore <i@shantur.com>