On 2/20/19 5:58 AM, AKASHI Takahiro wrote: > On Tue, Feb 19, 2019 at 08:32:52PM +0100, Heinrich Schuchardt wrote: >> On 1/24/19 12:04 PM, AKASHI Takahiro wrote: >>> Currently, there is no easy way to add or modify UEFI variables. >>> In particular, bootmgr supports BootOrder/BootXXXX variables, it is >>> quite hard to define them as u-boot variables because they are represented >>> in a complicated and encoded format. >>> >>> The new command, efidebug, helps address these issues and give us >>> more friendly interfaces: >>> * efidebug boot add: add BootXXXX variable >>> * efidebug boot rm: remove BootXXXX variable >>> * efidebug boot dump: display all BootXXXX variables >>> * efidebug boot next: set BootNext variable >>> * efidebug boot order: set/display a boot order (BootOrder) >>> >>> Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org> >> I could not make this work on qemu_arm_defconfig: >> >> Usage: >> efidebug boot add <bootid> <label> <interface> <device>[:<part>] <file >> path> [<load options>] >> >> => efidebug boot add 00AA 'fancy label' mmc 0:1 wonder.efi '--do-it' >> => efidebug boot dump >> => >> >> I would expect either an error or an output of `dump`. >> >> As the UEFI spec teaches: "Each Boot#### variable is the name “Boot” >> appended with a unique four digit hexadecimal number." So 00AA should be >> a valid id. > > It's not a problem. > The real issue is that you don't have "mmc 0:1" on you system > when typing this command. > > This error take places because this command internally uses > efi_dp_from_name(), hence blk_get_device_part_str(), which > requires that a block device does exist and it can be accessible > to see a partition table. > > I think that this is one of major issues in current device path > implementation. We never know how to convert "mmc 0:1" to a device > path without having the named device. > > Anyhow, I will add some error message in such a case. > > -Takahiro Akashi
=> scsi scan scanning bus for devices... Target spinup took 0 ms. SATA link 1 timeout. SATA link 2 timeout. SATA link 3 timeout. SATA link 4 timeout. SATA link 5 timeout. AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode flags: 64bit ncq only Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+ Type: Hard Disk Capacity: 128.9 MB = 0.1 GB (264190 x 512) => efidebug boot add 00AA 'fancy label' scsi 0:1 wonder.efi '--do-it' Scanning disk ahci_scsi.id0lun0... Found 2 disks e1000: 52:54:00:12:34:56 Warning: e1000#0 using MAC address from ROM => efidebug boot dump Boot00AA: attributes: A-- (0x00000001) label: fancy label file_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(1,MBR,0xcc8b40b9,0x800,0x3fffe)/\wonder.efi data: --do-it => env print -e Boot00AA Boot00AA: BS|RT, DataSize = 0x8c 00000000: 01 00 00 00 66 00 66 00 61 00 6e 00 63 00 79 00 ....f.f.a.n.c.y. 00000010: 20 00 6c 00 61 00 62 00 65 00 6c 00 00 00 01 04 .l.a.b.e.l..... 00000020: 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8 28 f3 ...s.....J....(. 00000030: 62 8b 03 02 08 00 00 00 00 00 04 01 2a 00 01 00 b...........*... 00000040: 00 00 00 08 00 00 00 00 00 00 fe ff 03 00 00 00 ................ 00000050: 00 00 b9 40 8b cc 00 00 00 00 00 00 00 00 00 00 ...@............ 00000060: 00 00 01 01 04 04 1c 00 5c 00 77 00 6f 00 6e 00 ........\.w.o.n. 00000070: 64 00 65 00 72 00 2e 00 65 00 66 00 69 00 00 00 d.e.r...e.f.i... 00000080: 7f ff 04 00 2d 2d 64 6f 2d 69 74 00 ....--do-it. worked on qemu_arm64_config. Yes, please, add the error message for an invalid device. That matches the behavior of the load command that will not work without prior device scanning. Best regards Heinrich _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot