1. 16 4月, 2020 3 次提交
  2. 23 3月, 2020 1 次提交
  3. 17 3月, 2020 1 次提交
  4. 29 2月, 2020 1 次提交
  5. 08 1月, 2020 5 次提交
  6. 19 11月, 2019 1 次提交
  7. 08 10月, 2019 1 次提交
  8. 21 9月, 2019 1 次提交
    • A
      efi_loader: device_path: support Sandbox's "host" devices · 23ad52ff
      AKASHI Takahiro 提交于
      Sandbox's "host" devices are currently described as UCLASS_ROOT udevice
      with DEV_IF_HOST block device. As the current implementation of
      efi_device_path doesn't support such a type, any "host" device
      on sandbox cannot be seen as a distinct object.
      
      For example,
        => host bind 0 /foo/disk.img
      
        => efi devices
        Scanning disk host0...
        Found 1 disks
        Device           Device Path
        ================ ====================
        0000000015c19970 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
        0000000015c19d70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
      
        => efi dh
        Handle           Protocols
        ================ ====================
        0000000015c19970 Device Path, Device Path To Text, Device Path Utilities, Unicode Collation 2, HII String, HII Database, HII Config Routing
        0000000015c19ba0 Driver Binding
        0000000015c19c10 Simple Text Output
        0000000015c19c80 Simple Text Input, Simple Text Input Ex
        0000000015c19d70 Block IO, Device Path, Simple File System
      
      As you can see here, efi_root (0x0000000015c19970) and host0 device
      (0x0000000015c19d70) have the same representation of device path.
      
      This is not only inconvenient, but also confusing since two different
      efi objects are associated with the same device path and
      efi_dp_find_obj() will possibly return a wrong result.
      
      Solution:
      Each "host" device should be given an additional device path node
      of "vendor device path" to make it distinguishable.
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      23ad52ff
  9. 09 9月, 2019 1 次提交
  10. 06 9月, 2019 1 次提交
  11. 17 7月, 2019 2 次提交
  12. 07 7月, 2019 4 次提交
  13. 15 6月, 2019 1 次提交
  14. 11 6月, 2019 2 次提交
  15. 01 6月, 2019 2 次提交
  16. 25 5月, 2019 1 次提交
  17. 19 5月, 2019 2 次提交
  18. 08 5月, 2019 4 次提交
  19. 03 5月, 2019 2 次提交
    • H
      efi_loader: implement support of exit data · 556d8dc9
      Heinrich Schuchardt 提交于
      In case of a failure exit data may be passed to Exit() which in turn is
      returned by StartImage().
      
      Let the `bootefi` command print the exit data string in case of an error.
      Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      556d8dc9
    • H
      efi_loader: optional data in load options are binary · 39a1ff8c
      Heinrich Schuchardt 提交于
      The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
      data.
      
      When we use `efidebug boot add` we should convert the 5th argument from
      UTF-8 to UTF-16 before putting it into the BootXXXX variable.
      
      When printing boot variables with `efidebug boot dump` we should support
      the OptionalData being arbitrary binary data. So let's dump the data as
      hexadecimal values.
      
      Here is an example session protocol:
      
      => efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
      => efidebug boot add 00a2 label2 scsi 0:1 doit2
      => efidebug boot dump
      Boot00A0:
        attributes: A-- (0x00000001)
        label: label1
        file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
        data:
          00000000: 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00  m.y. .o.p.t.i.o.
          00000010: 6e 00 00 00                                      n...
      Boot00A1:
        attributes: A-- (0x00000001)
        label: label2
        file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
        data:
      Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      39a1ff8c
  20. 23 4月, 2019 2 次提交
  21. 13 4月, 2019 1 次提交
  22. 07 4月, 2019 1 次提交