Kojima-san
[...]
We just followed the EDK2 reference implementation.
IOW if we pick this up, can we also use it on the efibootmgr code and scan all disks on the fly instead of adding boot options?
Yes, it is possible, but I'm not sure scanning all the disks on the fly is a good idea. For users, it is hard to control which device is selected to boot.
Now come to think of it, we add the one load option for each disk when the disk is detected, then try to boot with the default file by scanning the default boot file in the selected disk.
In current implementation, the following load options are automatically created.
Boot0000: attributes: A-- (0x00000001) label: virtio 0:1 file_path: /HD(1,GPT,b6b38698-f211-4d78-b208-f68e5523e588,0x800,0x100000) data: 00000000: c1 ac c1 38 c0 9f f0 41 b9 01 fa 74 d6 d6 e4 de ...8...A...t.... Boot0001: attributes: A-- (0x00000001) label: virtio 0:2 file_path: /HD(2,GPT,98533ff2-11d5-428c-b323-9afaf6b4abd8,0x100800,0x1122000) data: 00000000: c1 ac c1 38 c0 9f f0 41 b9 01 fa 74 d6 d6 e4 de ...8...A...t....
Yep, that's exactly what I was thinking as an alternative. On the automatically scan boot option, just search for '1234567' on the load options. Keep in mind that patch from Raymon is failing on an erofs selftest. But when I was looking at it, I came to the conclusion, that due to the EFI subsystem coming up earlier a print changes and that test gets utterly confused. IOW that patch seems fine, but you'll probably need to adjust a selftest as well.
Thanks /Ilias
For this disk, only the block device "virtio 0" load option is enough, we can search for the default boot file on the fly. This is what EDK2 does.
Thanks, Masahisa Kojima
+/**
- load_default_file_from_blk_dev() - load the default file
- @blk pointer to the UCLASS_BLK udevice
- @handle: pointer to handle for newly installed image
- Return: status code
- */
+static efi_status_t load_default_file_from_blk_dev(struct udevice *blk,
efi_handle_t *handle)+{
efi_status_t ret;struct udevice *partition;/* image that has no partition table but a file system */ret = try_load_default_file(blk, handle);if (ret == EFI_SUCCESS)return ret;/* try the partitions */device_foreach_child(partition, blk) {enum uclass_id id;id = device_get_uclass_id(partition);if (id != UCLASS_PARTITION)continue;ret = try_load_default_file(partition, handle);if (ret == EFI_SUCCESS)return ret;}return EFI_NOT_FOUND;+}
+/**
- try_load_from_uri_path() - Handle the URI device path
- @uridp: uri device path
- @lo_label label of load option
- @handle: pointer to handle for newly installed image
- Return: status code
- */
+static efi_status_t try_load_from_uri_path(struct efi_device_path_uri *uridp,
u16 *lo_label,efi_handle_t *handle)+{
char *s;int uri_len;int image_size;efi_status_t ret;ulong image_addr;s = env_get("loadaddr");if (!s) {log_err("Error: loadaddr is not set\n");return EFI_INVALID_PARAMETER;}image_addr = hextoul(s, NULL);image_size = wget_with_dns(image_addr, uridp->uri);if (image_size < 0)return EFI_INVALID_PARAMETER;/** If the file extension is ".iso" or ".img", mount it and try to load* the default file.Don't we have a better way to validate isos and efi apps instead of the extension? The efi is checked against a valid PE/COFF image so I guess we'll really on the mount to fail for isos?
EDK2 reference implementation checks the file type with the following priority.
- "Content-Type" header in HTTP response message
- Filename Extensions
Documentation is here[1].
Since "Content-Type" is not available in the current U-Boot wget, file extension is used to identify ISO images.
Ok fair enough, we can go back and improve this once lwip is merged I guess
[1] https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-boo...
[...]
Thanks /Ilias