[U-Boot] [PATCH v6 2/7] cmd: add efidebug command

Heinrich Schuchardt xypron.glpk at gmx.de
Wed Feb 20 06:40:54 UTC 2019


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.akashi at 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
... at ............
    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


More information about the U-Boot mailing list