On 5/8/19 1:56 AM, Takahiro Akashi wrote:
On Tue, May 07, 2019 at 06:54:45PM +0200, Heinrich Schuchardt wrote:
On 5/7/19 9:30 AM, Takahiro Akashi wrote:
On Tue, May 07, 2019 at 09:12:56AM +0200, Heinrich Schuchardt wrote:
On 5/7/19 8:16 AM, Takahiro Akashi wrote:
On Tue, May 07, 2019 at 08:04:26AM +0200, Heinrich Schuchardt wrote:
On 5/7/19 7:16 AM, Heinrich Schuchardt wrote:
On 5/7/19 3:53 AM, Takahiro Akashi wrote:
On Tue, Apr 30, 2019 at 08:11:15AM +0200, Heinrich Schuchardt wrote:
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.
While optional_data holds u8 string in calling
efi_serialize_load_option(),
it holds u16 string in leaving from efi_deserialize_load_option().
We should handle it in a consistent way if you want to keep optional_data
as "const u8."
When communicating with Linux optional data may contain a u16 string.
But I cannot see were our coding is inconsistent.
I don't get your point.
Do you want to allow 'u8 *' variable to hold u16 string?#
Yes, optional data may contain anything, in the case of Linux the
command line parameters as an u16 string.
Other operating systems may use the field in other ways, e.g. store an
ASCII string.
The problem is that with your patch optional_data is *always* converted
to utf-16 as far as we use efidebug.
My efidebug is not for linux only.
optional_data treated is not treated as u16 in efidebug:
With your patch,
efi_serialize_load_option() always convert a given argument to
utf-16 and then the resulting variable contains u16 string as
optional_data. On the other hand, efi_deserialize_load_option()
does *not* convert an encoded optional_data in a variable to utf-8.
When we use efi_serialize_load_option() we know that it is either an
UTF-8 string in the bootargs variable or UTF-8 command line parameter
for the `efi boot add` command. Currently we do not foresee adding
binary data. So we can simply convert the UTF-8 input to UTF-16 as will
be needed when passing the boot option to the operating system. (A patch
for the boot manager still to be delivered.)
But this is not the only way that BootXXXX variables can be set:
* An EFI application may be used to set an arbitrary binary string.
* In future an operating system could put some binary data into the load
option.
So it is not safe to convert the load option into UTF-8 for display.
That is why I chose to use print_hex_dump() for output. If your boot
option only contains ASCII letters it is still legible:
=> efi boot add f000 lable scsi 0:1 binary.efi 'my favorite option'
=> efi boot dump
BootF000:
attributes: A-- (0x00000001)
label: lable
file_path:
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(1,MBR,0x90381b6c,0x800,0x3fffe)/binary.efi
data:
00000000: 6d 00 79 00 20 00 66 00 61 00 76 00 6f 00 72 00 m.y.
.f.a.v.o.r.
00000010: 69 00 74 00 65 00 20 00 6f 00 70 00 74 00 69 00 i.t.e.
.o.p.t.i.
00000020: 6f 00 6e 00 00 00 o.n...
Best regards
Heinrich
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
