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

Reply via email to