* [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
@ 2019-01-24 3:17 krishnaLee
[not found] ` <A2150871-41DF-42B0-8131-1EF20D952F4F@apple.com>
0 siblings, 1 reply; 4+ messages in thread
From: krishnaLee @ 2019-01-24 3:17 UTC (permalink / raw)
To: edk2-devel
Hi,
I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is not the same as it showed in notepad++.
I had upload the log here:
https://github.com/krishna116/test/blob/master/log.zip
it seems the log showed in uefi shell had missed some strings...I don't know why,please help,
thank you,
by krishna.
\x16�&
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
[not found] ` <A2150871-41DF-42B0-8131-1EF20D952F4F@apple.com>
@ 2019-01-24 7:07 ` krishnaLee
2019-01-24 17:45 ` Andrew Fish
0 siblings, 1 reply; 4+ messages in thread
From: krishnaLee @ 2019-01-24 7:07 UTC (permalink / raw)
To: Andrew Fish; +Cc: edk2-devel
Andrew Fish,
thank you,in this case,you are right.
but I think there may be other case that the user data just contain some nosense-data
such as { UINT16 MyData[]={0x000c,0x000d,0x000d,0x000e} } to the editor,
the uefi editor may also meet this question,the editor may do not need output this,
but the editor should make sure other visible chars can output normal...
I don't know if it is a bug or not.
Thank you very much.
krishna.
�� 2019-01-24 12:13:50��"Andrew Fish" <afish@apple.com> ���
On Jan 23, 2019, at 7:17 PM, krishnaLee <sssky307@163.com> wrote:
Hi,
I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is not the same as it showed in notepad++.
I had upload the log here:
https://github.com/krishna116/test/blob/master/log.zip
it seems the log showed in uefi shell had missed some strings...I don't know why,please help,
Krishna,
Your log.txt looks like a normal UTF-16 Unicode file. The leading FF FE is the Byte order mark for UTF-16 Little Endian [1]. The file looks like it has CR line endings [2] so maybe that is confusing your editor? There seems to be a CR LF at the end, so the mixture of line ending may even be more likely confusing the editor. The byte order mark should let your editor know it is 16-bit Unicode and the correct endian. Hope this helps...
$ hexdump -C /Users/andrewfish/Downloads/log/log.txt
00000000 ff fe 20 00 20 00 20 00 4d 00 58 00 32 00 35 00 |.. . . .M.X.2.5.|
00000010 4c 00 31 00 32 00 38 00 37 00 35 00 46 00 20 00 |L.1.2.8.7.5.F. .|
00000020 20 00 20 00 20 00 49 00 44 00 3a 00 30 00 78 00 | . . .I.D.:.0.x.|
00000030 43 00 32 00 32 00 30 00 31 00 38 00 20 00 20 00 |C.2.2.0.1.8. . .|
00000040 20 00 20 00 53 00 69 00 7a 00 65 00 3a 00 20 00 | . .S.i.z.e.:. .|
00000050 31 00 36 00 33 00 38 00 34 00 4b 00 42 00 20 00 |1.6.3.8.4.K.B. .|
00000060 28 00 31 00 33 00 31 00 30 00 37 00 32 00 4b 00 |(.1.3.1.0.7.2.K.|
00000070 62 00 29 00 20 00 20 00 20 00 20 00 20 00 20 00 |b.). . . . . . .|
00000080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
000000c0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . ..... . .|
000000d0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000190 20 00 20 00 0d 00 0d 00 20 00 20 00 20 00 20 00 | . ..... . . . .|
000001a0 4d 00 58 00 32 00 35 00 4c 00 36 00 34 00 37 00 |M.X.2.5.L.6.4.7.|
000001b0 33 00 45 00 20 00 20 00 20 00 20 00 49 00 44 00 |3.E. . . . .I.D.|
000001c0 3a 00 30 00 78 00 43 00 32 00 32 00 30 00 31 00 |:.0.x.C.2.2.0.1.|
000001d0 37 00 20 00 20 00 20 00 20 00 53 00 69 00 7a 00 |7. . . . .S.i.z.|
000001e0 65 00 3a 00 20 00 38 00 31 00 39 00 32 00 4b 00 |e.:. .8.1.9.2.K.|
000001f0 42 00 20 00 28 00 36 00 35 00 35 00 33 00 36 00 |B. .(.6.5.5.3.6.|
00000200 4b 00 62 00 29 00 20 00 20 00 20 00 20 00 20 00 |K.b.). . . . . .|
00000210 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000260 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 |.... . . . . . .|
00000270 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000320 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .....|
00000330 53 00 50 00 49 00 20 00 42 00 41 00 52 00 3a 00 |S.P.I. .B.A.R.:.|
00000340 20 00 46 00 45 00 30 00 31 00 30 00 30 00 30 00 | .F.E.0.1.0.0.0.|
00000350 30 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 |0. . . . . . . .|
00000360 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
000003f0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . ..... . .|
00000400 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
000004c0 20 00 20 00 0d 00 0d 00 46 00 50 00 54 00 20 00 | . .....F.P.T. .|
000004d0 4f 00 70 00 65 00 72 00 61 00 74 00 69 00 6f 00 |O.p.e.r.a.t.i.o.|
000004e0 6e 00 20 00 53 00 75 00 63 00 63 00 65 00 73 00 |n. .S.u.c.c.e.s.|
000004f0 73 00 66 00 75 00 6c 00 2e 00 20 00 20 00 20 00 |s.f.u.l... . . .|
00000500 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000590 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 |.... . . . . . .|
000005a0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000650 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .....|
00000660 0d 00 0a 00 |....|
00000664
[1] https://en.wikipedia.org/wiki/Byte_order_mark#UTF-16
[2] https://en.wikipedia.org/wiki/Newline
Thanks,
Andrew Fish
thank you,
by krishna.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
\x16�&
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
2019-01-24 7:07 ` krishnaLee
@ 2019-01-24 17:45 ` Andrew Fish
2019-01-25 3:10 ` krishnaLee
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Fish @ 2019-01-24 17:45 UTC (permalink / raw)
To: krishnaLee; +Cc: edk2-devel
Krishna,
From an EFI point of view BackSpace 0x08, LF 0x0A, and CR 0xD are defined for a ConOut device.
From Ascii Control Codes:
0x0C - Form Feed
0x0E - Shift Out
The Shift Out is used with graphics characters.
How did you dump the log? If EFI sends data to a serial terminal then it would use terminal emulation and the output stream would look different.
Thanks,
Andrew Fish
> On Jan 23, 2019, at 11:07 PM, krishnaLee <sssky307@163.com> wrote:
>
> Andrew Fish,
> thank you,in this case,you are right.
> but I think there may be other case that the user data just contain some nosense-data
> such as { UINT16 MyData[]={0x000c,0x000d,0x000d,0x000e} } to the editor,
> the uefi editor may also meet this question,the editor may do not need output this,
> but the editor should make sure other visible chars can output normal...
>
> I don't know if it is a bug or not.
>
> Thank you very much.
> krishna.
>
>
>
>
> 在 2019-01-24 12:13:50，"Andrew Fish" <afish@apple.com> 写道：
>> On Jan 23, 2019, at 7:17 PM, krishnaLee <sssky307@163.com <mailto:sssky307@163.com>> wrote:
>>
>> Hi,
>> I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is not the same as it showed in notepad++.
>> I had upload the log here:
>> https://github.com/krishna116/test/blob/master/log.zip <https://github.com/krishna116/test/blob/master/log.zip>
>>
>>
>> it seems the log showed in uefi shell had missed some strings...I don't know why,please help,
>>
>
> Krishna,
>
> Your log.txt looks like a normal UTF-16 Unicode file. The leading FF FE is the Byte order mark for UTF-16 Little Endian [1]. The file looks like it has CR line endings [2] so maybe that is confusing your editor? There seems to be a CR LF at the end, so the mixture of line ending may even be more likely confusing the editor. The byte order mark should let your editor know it is 16-bit Unicode and the correct endian. Hope this helps...
>
> $ hexdump -C /Users/andrewfish/Downloads/log/log.txt
> 00000000 ff fe 20 00 20 00 20 00 4d 00 58 00 32 00 35 00 |.. . . .M.X.2.5.|
> 00000010 4c 00 31 00 32 00 38 00 37 00 35 00 46 00 20 00 |L.1.2.8.7.5.F. .|
> 00000020 20 00 20 00 20 00 49 00 44 00 3a 00 30 00 78 00 | . . .I.D.:.0.x.|
> 00000030 43 00 32 00 32 00 30 00 31 00 38 00 20 00 20 00 |C.2.2.0.1.8. . .|
> 00000040 20 00 20 00 53 00 69 00 7a 00 65 00 3a 00 20 00 | . .S.i.z.e.:. .|
> 00000050 31 00 36 00 33 00 38 00 34 00 4b 00 42 00 20 00 |1.6.3.8.4.K.B. .|
> 00000060 28 00 31 00 33 00 31 00 30 00 37 00 32 00 4b 00 |(.1.3.1.0.7.2.K.|
> 00000070 62 00 29 00 20 00 20 00 20 00 20 00 20 00 20 00 |b.). . . . . . .|
> 00000080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 000000c0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . ..... . .|
> 000000d0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 00000190 20 00 20 00 0d 00 0d 00 20 00 20 00 20 00 20 00 | . ..... . . . .|
> 000001a0 4d 00 58 00 32 00 35 00 4c 00 36 00 34 00 37 00 |M.X.2.5.L.6.4.7.|
> 000001b0 33 00 45 00 20 00 20 00 20 00 20 00 49 00 44 00 |3.E. . . . .I.D.|
> 000001c0 3a 00 30 00 78 00 43 00 32 00 32 00 30 00 31 00 |:.0.x.C.2.2.0.1.|
> 000001d0 37 00 20 00 20 00 20 00 20 00 53 00 69 00 7a 00 |7. . . . .S.i.z.|
> 000001e0 65 00 3a 00 20 00 38 00 31 00 39 00 32 00 4b 00 |e.:. .8.1.9.2.K.|
> 000001f0 42 00 20 00 28 00 36 00 35 00 35 00 33 00 36 00 |B. .(.6.5.5.3.6.|
> 00000200 4b 00 62 00 29 00 20 00 20 00 20 00 20 00 20 00 |K.b.). . . . . .|
> 00000210 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 00000260 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 |.... . . . . . .|
> 00000270 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 00000320 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .....|
> 00000330 53 00 50 00 49 00 20 00 42 00 41 00 52 00 3a 00 |S.P.I. .B.A.R.:.|
> 00000340 20 00 46 00 45 00 30 00 31 00 30 00 30 00 30 00 | .F.E.0.1.0.0.0.|
> 00000350 30 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 |0. . . . . . . .|
> 00000360 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 000003f0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . ..... . .|
> 00000400 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 000004c0 20 00 20 00 0d 00 0d 00 46 00 50 00 54 00 20 00 | . .....F.P.T. .|
> 000004d0 4f 00 70 00 65 00 72 00 61 00 74 00 69 00 6f 00 |O.p.e.r.a.t.i.o.|
> 000004e0 6e 00 20 00 53 00 75 00 63 00 63 00 65 00 73 00 |n. .S.u.c.c.e.s.|
> 000004f0 73 00 66 00 75 00 6c 00 2e 00 20 00 20 00 20 00 |s.f.u.l... . . .|
> 00000500 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 00000590 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 |.... . . . . . .|
> 000005a0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 00000650 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .....|
> 00000660 0d 00 0a 00 |....|
> 00000664
>
>
> [1] https://en.wikipedia.org/wiki/Byte_order_mark#UTF-16 <https://en.wikipedia.org/wiki/Byte_order_mark#UTF-16>
> [2] https://en.wikipedia.org/wiki/Newline <https://en.wikipedia.org/wiki/Newline>
>
> Thanks,
>
> Andrew Fish
>
>
>>
>> thank you,
>> by krishna.
>>
>>
>>
>>
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
2019-01-24 17:45 ` Andrew Fish
@ 2019-01-25 3:10 ` krishnaLee
0 siblings, 0 replies; 4+ messages in thread
From: krishnaLee @ 2019-01-25 3:10 UTC (permalink / raw)
To: Andrew Fish; +Cc: edk2-devel
Andrew Fish,
Yes,I know it ,from a terminal's view,the 0x0C/0x0D/0x0E/...,some invisible chars like this have special means,
and I also think from a text-editor's view, I think the text-editor just do not show them,and should make sure all visible chars can visible,
but I think I am wrong.
> How did you dump the log?
I got a piece of buffer from uefi-shell's screen-buffer,when I output my buffer,I find it is not correctly aligned as history output.
because the screen-buffer's width is 'terminal_column_size + 2',the last extra two UINT16 maked this question,
I think when the terminal output a full line(terminal_column_size),it will automatically go to new line's begin,
CR is means go to most left corner of screen,,so I make the last two char with "CR+CR",the cursor will stay at the new line's begin;
and make the (CHAR16==0) to (CHAR16==SPACE),so all lines are (full line+CR+CR),except last line end is (CR+LF),
and the result is aligned as the history showed.
but some times the result is missed some strings...
I may got what happened,the question is "...make the (CHAR16==0) to (CHAR16==SPACE),so all lines are (full line+CR+CR)"��
the lines may not all full line because some invisible will taken no space in terminal,it is not a full line,so CR+CR will make the line overlapped/disappeared.
I had mixed using text-editor's view and terminal's view in uefi,it's my fault.
I can duplicate this fault by follow test code:
//test-code-start
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS status;
EFI_SHELL_PROTOCOL* shell;
EFI_SHELL_PARAMETERS_PROTOCOL* param;
#defineONE_LINE (100+2)
CHAR16 buffer[ONE_LINE];
UINTN bufferSize = ONE_LINE *sizeof(CHAR16);
for(UINTN i=0;i<ONE_LINE;i++)
{
buffer[i]=0x0020;
}
buffer[ONE_LINE-8]=L'a';
buffer[ONE_LINE-7]=L'b';
buffer[ONE_LINE-6]=L'c';
buffer[ONE_LINE-4]=L'O';
buffer[ONE_LINE-3]=L'K';
buffer[ONE_LINE-2]=0x000D;
buffer[ONE_LINE-1]=0x000A;
status=gBS->LocateProtocol(&gEfiShellProtocolGuid,NULL,&(shell));
if(status!=EFI_SUCCESS)
{
return0;
}
status=gBS->HandleProtocol(gImageHandle,&gEfiShellParametersProtocolGuid,&(param));
if(status!=EFI_SUCCESS)
{
return0;
}
Print(L"test1:\n");
shell->WriteFile(param->StdOut,&bufferSize,buffer);
shell->FlushFile(param->StdOut);
Print(L"test2:\n");
buffer[ONE_LINE-9]=0x000D;
buffer[ONE_LINE-5]=0x000D;
shell->WriteFile(param->StdOut,&bufferSize,buffer);
shell->FlushFile(param->StdOut);
return EFI_SUCCESS;
}
//test-code-end
thank you,
krishna.
At 2019-01-25 01:45:00, "Andrew Fish" <afish@apple.com> wrote:
Krishna,
From an EFI point of view BackSpace 0x08, LF 0x0A, and CR 0xD are defined for a ConOut device.
From Ascii Control Codes:
0x0C - Form Feed
0x0E - Shift Out
The Shift Out is used with graphics characters.
How did you dump the log? If EFI sends data to a serial terminal then it would use terminal emulation and the output stream would look different.
Thanks,
Andrew Fish
On Jan 23, 2019, at 11:07 PM, krishnaLee <sssky307@163.com> wrote:
Andrew Fish,
thank you,in this case,you are right.
but I think there may be other case that the user data just contain some nosense-data
such as { UINT16 MyData[]={0x000c,0x000d,0x000d,0x000e} } to the editor,
the uefi editor may also meet this question,the editor may do not need output this,
but the editor should make sure other visible chars can output normal...
I don't know if it is a bug or not.
Thank you very much.
krishna.
�� 2019-01-24 12:13:50��"Andrew Fish" <afish@apple.com> ���
On Jan 23, 2019, at 7:17 PM, krishnaLee <sssky307@163.com> wrote:
Hi,
I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is not the same as it showed in notepad++.
I had upload the log here:
https://github.com/krishna116/test/blob/master/log.zip
it seems the log showed in uefi shell had missed some strings...I don't know why,please help,
Krishna,
Your log.txt looks like a normal UTF-16 Unicode file. The leading FF FE is the Byte order mark for UTF-16 Little Endian [1]. The file looks like it has CR line endings [2] so maybe that is confusing your editor? There seems to be a CR LF at the end, so the mixture of line ending may even be more likely confusing the editor. The byte order mark should let your editor know it is 16-bit Unicode and the correct endian. Hope this helps...
$ hexdump -C /Users/andrewfish/Downloads/log/log.txt
00000000 ff fe 20 00 20 00 20 00 4d 00 58 00 32 00 35 00 |.. . . .M.X.2.5.|
00000010 4c 00 31 00 32 00 38 00 37 00 35 00 46 00 20 00 |L.1.2.8.7.5.F. .|
00000020 20 00 20 00 20 00 49 00 44 00 3a 00 30 00 78 00 | . . .I.D.:.0.x.|
00000030 43 00 32 00 32 00 30 00 31 00 38 00 20 00 20 00 |C.2.2.0.1.8. . .|
00000040 20 00 20 00 53 00 69 00 7a 00 65 00 3a 00 20 00 | . .S.i.z.e.:. .|
00000050 31 00 36 00 33 00 38 00 34 00 4b 00 42 00 20 00 |1.6.3.8.4.K.B. .|
00000060 28 00 31 00 33 00 31 00 30 00 37 00 32 00 4b 00 |(.1.3.1.0.7.2.K.|
00000070 62 00 29 00 20 00 20 00 20 00 20 00 20 00 20 00 |b.). . . . . . .|
00000080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
000000c0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . ..... . .|
000000d0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000190 20 00 20 00 0d 00 0d 00 20 00 20 00 20 00 20 00 | . ..... . . . .|
000001a0 4d 00 58 00 32 00 35 00 4c 00 36 00 34 00 37 00 |M.X.2.5.L.6.4.7.|
000001b0 33 00 45 00 20 00 20 00 20 00 20 00 49 00 44 00 |3.E. . . . .I.D.|
000001c0 3a 00 30 00 78 00 43 00 32 00 32 00 30 00 31 00 |:.0.x.C.2.2.0.1.|
000001d0 37 00 20 00 20 00 20 00 20 00 53 00 69 00 7a 00 |7. . . . .S.i.z.|
000001e0 65 00 3a 00 20 00 38 00 31 00 39 00 32 00 4b 00 |e.:. .8.1.9.2.K.|
000001f0 42 00 20 00 28 00 36 00 35 00 35 00 33 00 36 00 |B. .(.6.5.5.3.6.|
00000200 4b 00 62 00 29 00 20 00 20 00 20 00 20 00 20 00 |K.b.). . . . . .|
00000210 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000260 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 |.... . . . . . .|
00000270 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000320 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .....|
00000330 53 00 50 00 49 00 20 00 42 00 41 00 52 00 3a 00 |S.P.I. .B.A.R.:.|
00000340 20 00 46 00 45 00 30 00 31 00 30 00 30 00 30 00 | .F.E.0.1.0.0.0.|
00000350 30 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 |0. . . . . . . .|
00000360 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
000003f0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . ..... . .|
00000400 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
000004c0 20 00 20 00 0d 00 0d 00 46 00 50 00 54 00 20 00 | . .....F.P.T. .|
000004d0 4f 00 70 00 65 00 72 00 61 00 74 00 69 00 6f 00 |O.p.e.r.a.t.i.o.|
000004e0 6e 00 20 00 53 00 75 00 63 00 63 00 65 00 73 00 |n. .S.u.c.c.e.s.|
000004f0 73 00 66 00 75 00 6c 00 2e 00 20 00 20 00 20 00 |s.f.u.l... . . .|
00000500 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000590 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 |.... . . . . . .|
000005a0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00000650 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .....|
00000660 0d 00 0a 00 |....|
00000664
[1] https://en.wikipedia.org/wiki/Byte_order_mark#UTF-16
[2] https://en.wikipedia.org/wiki/Newline
Thanks,
Andrew Fish
thank you,
by krishna.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
\x16�&
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-01-25 3:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-24 3:17 [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++ krishnaLee
[not found] ` <A2150871-41DF-42B0-8131-1EF20D952F4F@apple.com>
2019-01-24 7:07 ` krishnaLee
2019-01-24 17:45 ` Andrew Fish
2019-01-25 3:10 ` krishnaLee
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox