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" <af...@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 <sssky...@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" <af...@apple.com> 写道：
On Jan 23, 2019, at 7:17 PM, krishnaLee <sssky...@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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
