Re: [edk2] [PATCH] ShellPkg: Correct a parameter's name
Hi Shenglei, I am confused some times,see UEFI_Shell_specification_2_2,chapter-3.7: 3.7 File Names The UEFI Shell supports file names and paths with the following format: fs-path := [fs-map-name] [fs-divider][fs-dirs][fs-name] May be if the define name "fs-path" rename to "file-full-path-name" is more clear,:) thanks, krishna. At 2019-02-21 09:28:07, "Shenglei Zhang" wrote: >The parameter FilePath of ShellOpenFileByName defined in >ShellLib.h is incorrect. It should be FileName. >https://bugzilla.tianocore.org/show_bug.cgi?id=1221 > >Cc: Jaben Carsey >Cc: Ruiyu Ni >Contributed-under: TianoCore Contribution Agreement 1.1 >Signed-off-by: shenglei >--- > ShellPkg/Include/Library/ShellLib.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/ShellPkg/Include/Library/ShellLib.h >b/ShellPkg/Include/Library/ShellLib.h >index 2ecc5ee006..78bdcc8c53 100644 >--- a/ShellPkg/Include/Library/ShellLib.h >+++ b/ShellPkg/Include/Library/ShellLib.h >@@ -161,7 +161,7 @@ ShellOpenFileByDevicePath( > otherwise, the Filehandle is NULL. Attributes is valid only for > EFI_FILE_MODE_CREATE. > >- @param[in] FilePath The pointer to file name. >+ @param[in] FileName The pointer to file name. > @param[out] FileHandleThe pointer to the file handle. > @param[in] OpenMode The mode to open the file with. > @param[in] Attributes The file's file attributes. >@@ -186,7 +186,7 @@ ShellOpenFileByDevicePath( > EFI_STATUS > EFIAPI > ShellOpenFileByName( >- IN CONST CHAR16 *FilePath, >+ IN CONST CHAR16 *FileName, > OUT SHELL_FILE_HANDLE *FileHandle, > IN UINT64 OpenMode, > IN UINT64 Attributes >-- >2.18.0.windows.1 > >___ >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
Re: [edk2] [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
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_HANDLEImageHandle,
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;iLocateProtocol(&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" 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 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" 写道：
On Jan 23, 2019, at 7:17 PM, krishnaLee 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
ff fe 20 00 20 00 20 00 4d 00 58 00 32 00 35 00 |.. . . .M.X.2.5.|
0010 4c 00 31 00 32 00 38 00 37 00 35 00 46 00 20 00 |L.1.2.8.7.5.F. .|
0020 20 00 20 00 20 00 49 00 44 00 3a 00 30 00 78 00 | . . .I.D.:.0.x.|
0030 43 00 32 00 32 00 30 00 31 00 38 00 20 00 20 00 |C.2.2.0.1.8. . .|
0040 20 00 20 00 53 00 69 00 7a 00 65 00 3a 00 20 00 | . .S.i.z.e.:. .|
0050 31 00 36 00 33 00 38 00 34 00 4b 00 42 00 20 00 |1.6.3.8.4.K.B. .|
0060 28 00 31 00 33 00 31 00 30 00 37 00 32 00 4b 00 |(.1.3.1.0.7.2.K.|
0070 62 00 29 00 20 00 20 00 20 0
Re: [edk2] [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
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" 写道：
On Jan 23, 2019, at 7:17 PM, krishnaLee 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
ff fe 20 00 20 00 20 00 4d 00 58 00 32 00 35 00 |.. . . .M.X.2.5.|
0010 4c 00 31 00 32 00 38 00 37 00 35 00 46 00 20 00 |L.1.2.8.7.5.F. .|
0020 20 00 20 00 20 00 49 00 44 00 3a 00 30 00 78 00 | . . .I.D.:.0.x.|
0030 43 00 32 00 32 00 30 00 31 00 38 00 20 00 20 00 |C.2.2.0.1.8. . .|
0040 20 00 20 00 53 00 69 00 7a 00 65 00 3a 00 20 00 | . .S.i.z.e.:. .|
0050 31 00 36 00 33 00 38 00 34 00 4b 00 42 00 20 00 |1.6.3.8.4.K.B. .|
0060 28 00 31 00 33 00 31 00 30 00 37 00 32 00 4b 00 |(.1.3.1.0.7.2.K.|
0070 62 00 29 00 20 00 20 00 20 00 20 00 20 00 20 00 |b.). . . . . . .|
0080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
00c0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . . . .|
00d0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
0190 20 00 20 00 0d 00 0d 00 20 00 20 00 20 00 20 00 | . . . . . .|
01a0 4d 00 58 00 32 00 35 00 4c 00 36 00 34 00 37 00 |M.X.2.5.L.6.4.7.|
01b0 33 00 45 00 20 00 20 00 20 00 20 00 49 00 44 00 |3.E. . . . .I.D.|
01c0 3a 00 30 00 78 00 43 00 32 00 32 00 30 00 31 00 |:.0.x.C.2.2.0.1.|
01d0 37 00 20 00 20 00 20 00 20 00 53 00 69 00 7a 00 |7. . . . .S.i.z.|
01e0 65 00 3a 00 20 00 38 00 31 00 39 00 32 00 4b 00 |e.:. .8.1.9.2.K.|
01f0 42 00 20 00 28 00 36 00 35 00 35 00 33 00 36 00 |B. .(.6.5.5.3.6.|
0200 4b 00 62 00 29 00 20 00 20 00 20 00 20 00 20 00 |K.b.). . . . . .|
0210 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
0260 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . .|
0270 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
0320 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .|
0330 53 00 50 00 49 00 20 00 42 00 41 00 52 00 3a 00 |S.P.I. .B.A.R.:.|
0340 20 00 46 00 45 00 30 00 31 00 30 00 30 00 30 00 | .F.E.0.1.0.0.0.|
0350 30 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 |0. . . . . . . .|
0360 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
03f0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . . . .|
0400 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
04c0 20 00 20 00 0d 00 0d 00 46 00 50 00 54 00 20 00 | . .F.P.T. .|
04d0 4f 00 70 00 65 00 72 00 61 00 74 00 69 00 6f 00 |O.p.e.r.a.t.i.o.|
04e0 6e 00 20 00 53 00 75 00 63 00 63 00 65 00 73 00 |n. .S.u.c.c.e.s.|
04f0 73 00 66 00 75 00 6c 00 2e 00 20 00 20 00 20 00 |s.f.u.l... . . .|
0500 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
0590 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . .|
05a0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
*
0650 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .|
0660 0d 00 0a 00 ||
0664
[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
[edk2] [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
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. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] A question about shell-application's argument make system blocked;
Jaben,
>My question is if the comment character is valid on a command line typed in
>versus in a script file.
Maybe when parsing a script file,it should record a in-script-file-status,
and this command [ testapp.efi #abc ] in command line(not in a script file)
maybe looked as two argument (not one argument in current implementation).
thanks,
krishna.
At 2019-01-11 08:02:35, "Carsey, Jaben" wrote:
>Agreed. That seems like a bug that needs a Bugzilla filed.
>
>My question is if the comment character is valid on a command line typed in
>versus in a script file.
>
>> -Original Message-
>> From: jim.dai...@dell.com [mailto:jim.dai...@dell.com]
>> Sent: Thursday, January 10, 2019 3:34 PM
>> To: Carsey, Jaben
>> Cc: sssky...@163.com; edk2-devel@lists.01.org
>> Subject: RE: [edk2] A question about shell-application's argument make
>> system blocked;
>> Importance: High
>>
>> Jaben,
>>
>> The shell does not parse properly (my opinion) in some instances.
>> That is one of the reasons I wrote a separate parser for the shell I
>> maintain here at Dell.
>>
>> One of the areas I feel the parsing is wrong is when an unescaped "#"
>> is inside a quoted string:
>>
>> FS0:\> echo "This should # work."
>> Command Error Status: Invalid Parameter
>> FS0:\> echo "This should ^# work."
>> This should # work.
>> FS0:\>
>>
>> The first command is parsed as if this were the command line:
>>
>> FS0:\> echo "This should
>> Command Error Status: Invalid Parameter
>> FS0:\>
>>
>> I think many people would expect certain characters inside a quoted
>> string, like "#" for example, to NOT need escaping. The only ones
>> that should need escaping (again IMHO) are: ", ^, and %.
>>
>> Regards,
>> Jim
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Carsey, Jaben
>> Sent: Thursday, January 10, 2019 9:16 AM
>> To: krishnaLee; edk2-devel@lists.01.org
>> Subject: Re: [edk2] A question about shell-application's argument make
>> system blocked;
>>
>>
>> Is this in a script file? I don't remember how "comments" work on raw
>> command lines where the user types them.
>>
>> -Jaben
>>
>>
>> > -Original Message-
>> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> > krishnaLee
>> > Sent: Wednesday, January 09, 2019 10:13 PM
>> > To: edk2-devel@lists.01.org
>> > Subject: [edk2] A question about shell-application's argument make system
>> > blocked;
>> > Importance: High
>> >
>> > Hi everybody,
>> > I meet a question,a special arg can make system blocked,follow is my steps.
>> > 1,go to uefi shell v2.2(uefi v2.70),run this application in QEMU-ovmf:
>> > testapp.efi
>> > 2,the output is "index:0,string:FS0:\testapp.efi"
>> >
>> >
>> > 3,testapp.efi #abc.
>> > 4,the output is same as step 2. ///< I had read the uefi shell
>> > specification
>> > 2.2,the '#' is a comment remark,so I think it is ok.
>> >
>> >
>> > 5 testapp.efi "#abc"
>> > 6,the system blocked(dead). ///< I think it is a bug.
>> >
>> >
>> > //follow is the testapp.efi source code:
>> > EFI_STATUS
>> > EFIAPI
>> > UefiMain (
>> > IN EFI_HANDLE ImageHandle,
>> > IN EFI_SYSTEM_TABLE *SystemTable
>> > )
>> > {
>> > EFI_STATUS status;
>> > EFI_SHELL_PARAMETERS_PROTOCOL* param;
>> > status=SystemTable->BootServices-
>> >
>> >HandleProtocol(ImageHandle,&gEfiShellParametersProtocolGuid,¶m);
>> > if(status!=EFI_SUCCESS)
>> > {
>> > return0;
>> > }
>> >
>> >
>> > for(UINTN i=0;i< param->Argc;i++)
>> > {
>> > Print(L"index:%d,string:%s\n",i,param->Argv[i]);
>> > }
>> >
>> >
>> > return EFI_SUCCESS;
>> > }
>> >
>> >
>> > //test environment:
>> > //QEMU v2.10.95 + edk2-2018-ovmf-x64.
>> > //shell command line:
>> > //"D:\qemu\qemu-system-x86_64.exe" -machine pc-q35-2.9 -pflash
>> > "D:\qemu\bios\OVMF_x64_debug.fd" -serial stdio -hda fat:rw:G:\temp -
>> net
>> > none
>> > //end
>> >
>> >
>> >
>> >
>> >
>> >
>> > thanks,
>> > 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] A question about shell-application's argument make system blocked;
Hi everybody,
I meet a question,a special arg can make system blocked,follow is my steps.
1,go to uefi shell v2.2(uefi v2.70),run this application in QEMU-ovmf:
testapp.efi
2,the output is "index:0,string:FS0:\testapp.efi"
3,testapp.efi #abc.
4,the output is same as step 2. ///< I had read the uefi shell specification
2.2,the '#' is a comment remark,so I think it is ok.
5 testapp.efi "#abc"
6,the system blocked(dead). ///< I think it is a bug.
//follow is the testapp.efi source code:
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS status;
EFI_SHELL_PARAMETERS_PROTOCOL* param;
status=SystemTable->BootServices->HandleProtocol(ImageHandle,&gEfiShellParametersProtocolGuid,¶m);
if(status!=EFI_SUCCESS)
{
return0;
}
for(UINTN i=0;i< param->Argc;i++)
{
Print(L"index:%d,string:%s\n",i,param->Argv[i]);
}
return EFI_SUCCESS;
}
//test environment:
//QEMU v2.10.95 + edk2-2018-ovmf-x64.
//shell command line:
//"D:\qemu\qemu-system-x86_64.exe" -machine pc-q35-2.9 -pflash
"D:\qemu\bios\OVMF_x64_debug.fd" -serial stdio -hda fat:rw:G:\temp -net none
//end
thanks,
krishna.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Proposal to add edk2-apps repository
Ruiyu, At 2018-11-30 11:40:06, "Ni, Ruiyu" wrote: >I don't prefer edk2-libc unless we have a strategy/plan to make ordinary C >developer easy by promoting the std-c pkg. >The other reason I prefer edk2-app is then ShellPkg might be moved to that new >repo. I used to think ShellPkg can also develop apps has no dependency on it or libc,it would be a big app-container,but it seems its name will be mis-understanding... I think your idea has the same function,and it's much better. thanks, krishna. >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> krishnaLee >> Sent: Friday, November 30, 2018 9:45 AM >> To: edk2-devel@lists.01.org >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository >> >> Kinney, >> I always think there may be two kinds of apps: >> 1,some apps have dependency on >> uefi_shell(shell-lib,efi_shell_protocol,...they >> usually execute under uefi_shell),I would call them "uefi_shell_application"; >> 2,some apps have no dependency on uefi_shell(such as apps in >> MdeModulePkg/Application),I would call them "standard_uefi_application". >> >> The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used >> by >> uefi_shell_application,I think they can all move to ShellPkg,no need to >> create >> new package ? >> >> >> Thanks, >> krishna. >> >> At 2018-11-30 08:46:58, "Kinney, Michael D" >> wrote: >> >Leif, >> > >> >I did consider the edk2-libc name. The port of Python 2.7 is in the >> >AppPkg as well and it uses libc. >> > >> >So the content of this new package is a combination of libc And apps >> >that use libc. >> > >> >I am definitely open to alternate names. 2 options so far: >> > >> >* edk2-apps >> >* edk2-libc >> > >> >Thanks, >> > >> >Mike >> > >> >> -Original Message- >> >> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] >> >> Sent: Thursday, November 29, 2018 2:41 PM >> >> To: Kinney, Michael D >> >> Cc: edk2-devel@lists.01.org >> >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository >> >> >> >> On Thu, Nov 29, 2018 at 05:58:08PM +, Kinney, Michael D wrote: >> >> > Hello, >> >> > >> >> > I would like to propose the creation of a new repository called >> >> > edk2-apps. This repository would initially be used to host the >> >> > following packages from the edk2 repository: >> >> > >> >> > * AppPkg >> >> > * StdLib >> >> > * StdLibPrivateInternalFiles >> >> >> >> Let me start by saying I 100% back moving these out of the main edk2 >> >> repository. >> >> >> >> > These 3 packages provide support for the libc along with >> >> > applications that depend on libc. None of the other packages in >> >> > the edk2 repository use these packages, so these 3 package can be >> >> > safely moved without any impacts to platform firmware builds. >> >> > Build configurations that do use libc features can clone the >> >> > edk2-apps repository and add it to PACKAGES_PATH. >> >> >> >> I must confess to never having properly understood the scope of >> >> AppPkg to begin with. >> >> >> >> AppPkg/Applications/Hello does not appear to have any further (real) >> >> dependency on libc than MdeModulePkg/Application/HelloWorld/, and . >> >> >> >> And certainly MdeModulePkg/Applications contain plenty of ... >> >> applications. >> >> >> >> So, if the purpose is simply to provide some examples of application >> >> written to libc rather than UEFI - should this be edk2- libc instead? >> >> >> >> Best Regards, >> >> >> >> Leif >> >> >> >> > The history of these 3 packages would be preserved when importing >> >> > the content into edk2-apps. After The import is verified, these 3 >> >> > packages would be deleted from the edk2 repository. >> >> > >> >> > This proposal helps reduce the size of the edk2 repository and >> >> > focuses edk2 repository on packages used to provide UEFI/PI >> >> > conformant firmware. >> >> > >> >> > If there are no concerns with this proposal, I will enter a >> >> > Tianocore BZs for the two steps. >> >> > >> >> > Best regards, >> >> > >> >> > Mike >> >> > ___ >> >> > 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 >> ___ >> 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
Re: [edk2] [RFC] Proposal to add edk2-apps repository
Kinney, I always think there may be two kinds of apps: 1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,...they usually execute under uefi_shell),I would call them "uefi_shell_application"; 2,some apps have no dependency on uefi_shell(such as apps in MdeModulePkg/Application),I would call them "standard_uefi_application". The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used by uefi_shell_application,I think they can all move to ShellPkg,no need to create new package ? Thanks, krishna. At 2018-11-30 08:46:58, "Kinney, Michael D" wrote: >Leif, > >I did consider the edk2-libc name. The port of Python 2.7 >is in the AppPkg as well and it uses libc. > >So the content of this new package is a combination of libc >And apps that use libc. > >I am definitely open to alternate names. 2 options so far: > >* edk2-apps >* edk2-libc > >Thanks, > >Mike > >> -Original Message- >> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] >> Sent: Thursday, November 29, 2018 2:41 PM >> To: Kinney, Michael D >> Cc: edk2-devel@lists.01.org >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps >> repository >> >> On Thu, Nov 29, 2018 at 05:58:08PM +, Kinney, Michael >> D wrote: >> > Hello, >> > >> > I would like to propose the creation of a new >> > repository called edk2-apps. This repository >> > would initially be used to host the following >> > packages from the edk2 repository: >> > >> > * AppPkg >> > * StdLib >> > * StdLibPrivateInternalFiles >> >> Let me start by saying I 100% back moving these out of the >> main edk2 >> repository. >> >> > These 3 packages provide support for the libc along >> > with applications that depend on libc. None of the >> > other packages in the edk2 repository use these >> > packages, so these 3 package can be safely moved >> > without any impacts to platform firmware builds. >> > Build configurations that do use libc features can >> > clone the edk2-apps repository and add it to >> > PACKAGES_PATH. >> >> I must confess to never having properly understood the >> scope of AppPkg >> to begin with. >> >> AppPkg/Applications/Hello does not appear to have any >> further (real) >> dependency on libc than >> MdeModulePkg/Application/HelloWorld/, and . >> >> And certainly MdeModulePkg/Applications contain plenty of >> ... applications. >> >> So, if the purpose is simply to provide some examples of >> application >> written to libc rather than UEFI - should this be edk2- >> libc instead? >> >> Best Regards, >> >> Leif >> >> > The history of these 3 packages would be preserved >> > when importing the content into edk2-apps. After >> > The import is verified, these 3 packages would be >> > deleted from the edk2 repository. >> > >> > This proposal helps reduce the size of the edk2 >> > repository and focuses edk2 repository on packages >> > used to provide UEFI/PI conformant firmware. >> > >> > If there are no concerns with this proposal, I will >> > enter a Tianocore BZs for the two steps. >> > >> > Best regards, >> > >> > Mike >> > ___ >> > 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 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] edk2-BaseTools-win32: Add notes to announce BaseTools Win32 doesn't work
Hi, I think someone needs update the wiki if the BaseTools_win32_bin no longer work, https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems thanks, krishna. At 2018-10-10 08:33:19, "Liming Gao" wrote: >https://lists.01.org/pipermail/edk2-devel/2018-September/029436.html > >Contributed-under: TianoCore Contribution Agreement 1.1 >Signed-off-by: Liming Gao >--- > Readme.txt | 5 + > 1 file changed, 5 insertions(+) > >diff --git a/Readme.txt b/Readme.txt >index 9caee63..793d1cd 100644 >--- a/Readme.txt >+++ b/Readme.txt >@@ -1,3 +1,8 @@ >+### NOTE ### >+This directory Win32 binaries doesn't work any longer to build EDK2 project. >+Please run BaseTools Python from source in Windows OS. Here is wiki: >+https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems#compile-tools >+ > Intel is a trademark or registered trademark of Intel Corporation or its > subsidiaries in the United States and other countries. > * Other names and brands may be claimed as the property of others. >-- >2.10.0.windows.1 > >___ >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
Re: [edk2] question about uefi shell-current working directory and shell-script
Carsey, The shell may not have a file system assigned, yes but when it find the stript(startup.nsh) file,it has the default file system-->the startup.nsh's file system, so the default cwd should exist,I think it is strange that start doing script without a default cwd, currently, without a default cwd,some people have to write ugly script to make a default cwd like this: if exist fs0:\mytool.efi then fs0: goto work_label if exist fs1:\mytool.efi then fs1: goto work_label if exist fs2:\mytool.efi then fs2: goto work_label if exist fs3:\mytool.efi then fs3: goto work_label ... At 2018-09-20 22:21:58, "Carsey, Jaben" wrote: >When the shell starts, it the prompt "shell>" or something like "fs0:>"... The >shell may not have a file system assigned yet so you cannot change directories >until you pick a file system. > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> krishnaLee >> Sent: Thursday, September 20, 2018 2:22 AM >> To: edk2-devel@lists.01.org >> Subject: [edk2] question about uefi shell-current working directory and >> shell- >> script >> Importance: High >> >> Hi, >> I wonder if it is a bug: >> I have a usb Fat32-disk,installed with EDK2 shell2.6 or 2.7, >> the root directory has a startup.nsh,the startup.nsh has only one line:"cd >> \", >> I boot my cannolake machine with this usb disk, >> in the uefi shell,I got a message:"cd: current directory not specified".it >> means >> the cwd environment variable was not set when start doing script. >> >> >> I think it may be an error,because the uefi shell can find the >> startup.nsh,why >> not set cwd(current working directory) before execute this script,so the cd >> command works fine. >> I mention it because I found if I put a uefi application(using >> efi_shell_protocol >> to access .\logfile.txt) in this startup.nsh,the uefi application can't >> access files, >> because I found the efi_shell_protocol need cwd to work too,such as >> efi_shell_protocol.OpenFileByName(). >> >> >> >> >> >> >> thank you, >> 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
[edk2] question about uefi shell-current working directory and shell-script
Hi, I wonder if it is a bug: I have a usb Fat32-disk,installed with EDK2 shell2.6 or 2.7, the root directory has a startup.nsh,the startup.nsh has only one line:"cd \", I boot my cannolake machine with this usb disk, in the uefi shell,I got a message:"cd: current directory not specified".it means the cwd environment variable was not set when start doing script. I think it may be an error,because the uefi shell can find the startup.nsh,why not set cwd(current working directory) before execute this script,so the cd command works fine. I mention it because I found if I put a uefi application(using efi_shell_protocol to access .\logfile.txt) in this startup.nsh,the uefi application can't access files, because I found the efi_shell_protocol need cwd to work too,such as efi_shell_protocol.OpenFileByName(). thank you, krishna ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/12] Add WinHost support in EmulatorPkg
Hi, It's a good idea,besides the code,I also think it is bettter to put out some design note to help newbie/user/developer,it may be useful to many people,such as: Emulator_user_guide.pdf, Emulator_developer_guide.pdf, the implementation_of_Emulator.pdf the implementation_of_Emulator's xxx .pdf How does Emulator's something worked.pdf thank you, by krishna. At 2018-09-04 10:32:09, "Ni, Ruiyu" wrote: >Shia, >This is my personal plan. But I need to: >1. make EmulatorPkg/Win be functionality equivalent to Nt32Pkg >2. All existing Nt32Pkg customers are happy to use EmulatorPkg/Win > >Until then, I may remove Nt32Pkg. >Again, this is my personal plan, not an official decision. > >Any comments? > >> -Original Message- >> From: Shia, Cinnamon [mailto:cinnamon.s...@hpe.com] >> Sent: Thursday, August 30, 2018 9:58 AM >> To: Ni, Ruiyu ; edk2-devel@lists.01.org >> Subject: RE: [edk2] [PATCH v2 00/12] Add WinHost support in EmulatorPkg >> >> Hi Ray, >> >> Does this change mean that Nt32Pkg is going to be retired? >> >> Thanks >> Cinnamon Shia >> >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu >> Ni >> Sent: Thursday, August 23, 2018 5:56 PM >> To: edk2-devel@lists.01.org >> Subject: [edk2] [PATCH v2 00/12] Add WinHost support in EmulatorPkg >> >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1112 >> >> The patch sets add WinHost support (Nt32) in EmulatorPkg. >> 3 EmulatorPkg common issues were found and fixed. >> Other 9 patches are to step-by-step enable the WinHost. >> >> v2 sends to correct mail address. >> >> Ruiyu Ni (12): >> EmulatorPkg/ThunkProtocolList: Fix VS build failure >> EmulatorPkg/Win: Add Windows host support >> EmulatorPkg/Win: Enable source level debugging >> EmulatorPkg/Win: Enable native OS console as firmware console >> EmulatorPkg/Win: Add input/output support >> EmulatorPkg/Win: Add timer and interrupt support >> EmulatorPkg/Win: Add RTC support >> EmulatorPkg/Win: Add SimpleFileSystem support >> EmulatorPkg/Win: Add BlockIo support >> EmulatorPkg/PlatformBds: Signal EndOfDxe in platform BDS >> EmulatorPkg/EmuFileSystem: Fix a bug that causes Close() assertion >> EmulatorPkg/DSC: Remove FS mapping to EDK Shell bin directory >> >> .../EmuSimpleFileSystemDxe/EmuSimpleFileSystem.c | 33 +- >> EmulatorPkg/EmulatorPkg.dsc| 17 +- >> EmulatorPkg/Library/EmuBdsLib/BdsPlatform.c|4 +- >> EmulatorPkg/Library/EmuBdsLib/BdsPlatform.h|4 +- >> EmulatorPkg/Library/EmuBdsLib/EmuBdsLib.inf|5 +- >> .../Library/ThunkProtocolList/ThunkProtocolList.c |4 +- >> EmulatorPkg/Win/Host/WinBlockIo.c | 563 + >> EmulatorPkg/Win/Host/WinFileSystem.c | 2409 >> >> EmulatorPkg/Win/Host/WinGop.h | 204 ++ >> EmulatorPkg/Win/Host/WinGopInput.c | 417 >> EmulatorPkg/Win/Host/WinGopScreen.c| 872 +++ >> EmulatorPkg/Win/Host/WinHost.c | 947 >> EmulatorPkg/Win/Host/WinHost.h | 209 ++ >> EmulatorPkg/Win/Host/WinHost.inf | 107 + >> EmulatorPkg/Win/Host/WinInclude.h | 75 + >> EmulatorPkg/Win/Host/WinMemoryAllocationLib.c | 178 ++ >> EmulatorPkg/Win/Host/WinThunk.c| 577 + >> 17 files changed, 6614 insertions(+), 11 deletions(-) create mode 100644 >> EmulatorPkg/Win/Host/WinBlockIo.c create mode 100644 >> EmulatorPkg/Win/Host/WinFileSystem.c >> create mode 100644 EmulatorPkg/Win/Host/WinGop.h create mode 100644 >> EmulatorPkg/Win/Host/WinGopInput.c >> create mode 100644 EmulatorPkg/Win/Host/WinGopScreen.c >> create mode 100644 EmulatorPkg/Win/Host/WinHost.c create mode 100644 >> EmulatorPkg/Win/Host/WinHost.h create mode 100644 >> EmulatorPkg/Win/Host/WinHost.inf create mode 100644 >> EmulatorPkg/Win/Host/WinInclude.h create mode 100644 >> EmulatorPkg/Win/Host/WinMemoryAllocationLib.c >> create mode 100644 EmulatorPkg/Win/Host/WinThunk.c >> >> -- >> 2.16.1.windows.1 >> >> ___ >> 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 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] question about uefi calling convention
thank you,Laszlo. krishna. At 2018-08-14 21:54:03, "Laszlo Ersek" wrote: >On 08/14/18 11:09, krishnaLee wrote: >> Hi, >> In uefi 2.6 specification -> 2.3.4 x64 Platforms, >> "Paging mode is enabled and any memory space defined by the UEFI memory map >> is identity mapped (virtual address equals physical address)" ... >> is that mean if I write C code like " void *pointer=0xabcd",the pointer is >> virtual address ,is equal to the physical address, and they are the same? > >Yes. > >> How the virtual address translate from "CR3->Page Base address,Page >> directory,page table ..." to physical address in "x64 Long mode,64-bit >> mode"? is there any sample not theory? > >The page tables are built in the DXE IPL PEIM, function >CreateIdentityMappingPageTables(). > >Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] question about uefi calling convention
Hi, In uefi 2.6 specification -> 2.3.4 x64 Platforms, "Paging mode is enabled and any memory space defined by the UEFI memory map is identity mapped (virtual address equals physical address)" ... is that mean if I write C code like " void *pointer=0xabcd",the pointer is virtual address ,is equal to the physical address, and they are the same? How the virtual address translate from "CR3->Page Base address,Page directory,page table ..." to physical address in "x64 Long mode,64-bit mode"? is there any sample not theory? thank you, krishna. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] question about uefi shell pipe.
Hi,liming:
the files attached to this mail may be missed,so I had made a copy here:
https://github.com/testcheng307/UEFI-TEST
the question is in first mail,I repeat it here:
# test-1,the follow two command should has the same output ,but infact not the
same in QEMU,and the second command failed WriteFile in real machine(AMI bios
uefi 2.6):
# the smalltest.efi 's fullsource code is in my first mail;
ls | smalltest.efi
ls | smalltest.efi | smalltest.efi
#test-2
run smalltest.efi,
just key in some chars, and I can not end input by press Enter or[Ctrl+C] or
[Ctrl+Z], so nothing output,why?
#test-3,the follow two command will be the same.
ls | grep -trim-last 0
ls | grep -trim-last 0 | grep -trim-last 0
# my grep.efi tool will process input buffer like this:
1,before pipe out the buffer,trim off all in-visible wchars at end of this
buffer,
(the trimed of wchar is "like ASCII's range of" 0x~0x0020. )
2,always make sure outputBuffer[lastTwoWchar] = { 0x000A,0x000D },it will
also bypass many other strange result.
thank you,
by krishna.
At 2018-07-09 15:17:56, "Gao, Liming" wrote:
>Krishna:
> Sorry, I am not clear what's your question here? Would you like to share this
> grep.efi tool? Or you meet with the problem in this grep.efi tool?
>
>Thanks
>Liming
>>-Original Message-
>>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>krishnaLee
>>Sent: Friday, July 06, 2018 11:35 AM
>>To: krishnaLee
>>Cc: edk2-devel@lists.01.org
>>Subject: Re: [edk2] question about uefi shell pipe.
>>
>>
>>
>>Hi,All:
>>may be I should reply this to EDK2 group,I had attached my file again.
>>
>>
>>After many test,my right key of "ls | grep -trim-last 0 | grep -trim-last 0"
>>is:
>> 1,before pipe out the buffer,trim off all in-visible wchars at end of this
>> buffer,
>>(the trimed of wchar is "like ASCII's range of" 0x~0x0020. )
>> 2,always make sure outputBuffer[lastTwoWchar] = { 0x000A,0x000D },it will
>>also bypass many other strange result.
>>
>>
>>thank you,
>>by krishna.
>>
>>
>>
>>
>>
>>At 2018-07-06 11:07:05, "krishnaLee" wrote:
>>
>>Jim,
>>I attached the smalltest.efi if you have not compiled the test code.
>>
>>
>>I am in developing of this grep.efi tool,I can now bypass the test-1 question
>>by follow command:
>>ls | grep -trim-last 0
>>ls | grep -trim-last 0 | grep -trim-last 0
>>
>>
>>I also attached this grep.efi tool, it almost ok :)
>>
>>
>>//draft usage guide-
>>
>>
>>//if find ok,returncode 1,Print(string);else returncode 0;
>>grep.efi -find string
>>
>>
>>//get first word,
>>//the front and the end in-visible chars of this word will be trimed off;
>>grep.efi -first
>>
>>
>>//get back part after the string.
>>
>>grep.efi -begin-at string
>>
>>
>>//get front part before the string
>>grep.efi -end-at string
>>
>>
>>//trim off first n chars at front
>>//before start -trim-first,the front in-visible chars will be trimed off;
>>grep.efi -trim-first n
>>
>>
>>//trim off back n chars at end,
>>//before start -trim-last,the end in-visible chars will be trimed off;
>>grep.efi -trim-last n
>>
>>
>>//trim off whitespace at front and end,
>>//trim off in-visible chars infact;
>>grep.efi -trim-space
>>
>>
>>
>>
>>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
Re: [edk2] question about uefi shell pipe.
Hi,All:
may be I should reply this to EDK2 group,I had attached my file again.
After many test,my right key of "ls | grep -trim-last 0 | grep -trim-last 0" is:
1,before pipe out the buffer,trim off all in-visible wchars at end of this
buffer, (the trimed of wchar is "like ASCII's range of" 0x~0x0020. )
2,always make sure outputBuffer[lastTwoWchar] = { 0x000A,0x000D },it will
also bypass many other strange result.
thank you,
by krishna.
At 2018-07-06 11:07:05, "krishnaLee" wrote:
Jim,
I attached the smalltest.efi if you have not compiled the test code.
I am in developing of this grep.efi tool,I can now bypass the test-1 question
by follow command:
ls | grep -trim-last 0
ls | grep -trim-last 0 | grep -trim-last 0
I also attached this grep.efi tool, it almost ok :)
//draft usage guide-
//if find ok,returncode 1,Print(string);else returncode 0;
grep.efi -find string
//get first word,
//the front and the end in-visible chars of this word will be trimed off;
grep.efi -first
//get back part after the string.
grep.efi -begin-at string
//get front part before the string
grep.efi -end-at string
//trim off first n chars at front
//before start -trim-first,the front in-visible chars will be trimed off;
grep.efi -trim-first n
//trim off back n chars at end,
//before start -trim-last,the end in-visible chars will be trimed off;
grep.efi -trim-last n
//trim off whitespace at front and end,
//trim off in-visible chars infact;
grep.efi -trim-space
thank you,
by krishna.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] question about uefi shell pipe.
Hi,All:
may be I should reply this to EDK2 group,sorry for this mail-size>600K,I had
trim the picture and attached my file again,and send it again.
After many test,my right key of "ls | grep -trim-last 0 | grep -trim-last 0" is:
1,before pipe out the buffer,trim off all in-visible wchars at end of this
buffer, (the trimed of wchar is "like ASCII's range of" 0x~0x0020. )
2,always make sure outputBuffer[lastTwoWchar] = { 0x000A,0x000D },it will
also bypass many other strange result.
thank you,
by krishna.
At 2018-07-06 11:07:05, "krishnaLee" wrote:
Jim,
I attached the smalltest.efi if you have not compiled the test code.
I am in developing of this grep.efi tool,I can now bypass the test-1 question
by follow command:
ls | grep -trim-last 0
ls | grep -trim-last 0 | grep -trim-last 0
I also attached this grep.efi tool, it almost ok :)
//draft usage guide-
//if find ok,returncode 1,Print(string);else returncode 0;
grep.efi -find string
//get first word,
//the front and the end in-visible chars of this word will be trimed off;
grep.efi -first
//get back part after the string.
grep.efi -begin-at string
//get front part before the string
grep.efi -end-at string
//trim off first n chars at front
//before start -trim-first,the front in-visible chars will be trimed off;
grep.efi -trim-first n
//trim off back n chars at end,
//before start -trim-last,the end in-visible chars will be trimed off;
grep.efi -trim-last n
//trim off whitespace at front and end,
//trim off in-visible chars infact;
grep.efi -trim-space
thank you,
by krishna.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] question about uefi shell pipe.
Andrew Fish,
Yes,some times I am work in C++,thanks for correct this,but if I use this:
UINT16 Buffer[80*25*4]; //tool's buffer;
UINTN BufferByteSize = sizeof(Buffer);
it still cannot work.
I had checked the read size( gShell->ReadFile(gParameters->StdIn,...)) before I
post my question,it just read some hundred of bytes,It seems the question is
not about overflow...
so I want to know if I'm wrong or it is a bug?
thank you,
by krishna.
At 2018-07-04 22:55:27, "Andrew Fish" wrote:
>Krishnal,
>
>Thanks for including the code. You are overflowing the buffer. In C
>sizeof(Buffer) will be 80*25*4*2 since sizeof(UINT16) is 2. Your code is
>passing in double the size of the buffer.
>
>UINT16 Buffer[80*25*4]; //tool's buffer;
>UINTN BufferSize=sizeof(Buffer);
>UINTN BufferByteSize=BufferSize*sizeof(UINT16);
>
>This should work:
>
>UINT16 Buffer[80*25*4]; //tool's buffer;
>UINTN BufferByteSize = sizeof(Buffer);
>
>Thanks,
>
>Andrew Fish
>
>> On Jul 4, 2018, at 2:15 AM, krishnaLee wrote:
>>
>> Hi,
>> I wrote this shell application(smalltest.efi),did some pipe function
>> test,find some strange result.
>> boot into shell:
>>
>>
>> # test-1,the follow two command should has the same output ,but infact not
>> the same in QEMU,and the second command failed WriteFile in real machine(AMI
>> bios uefi 2.6):
>> ls | smalltest.efi
>> ls | smalltest.efi | smalltest.efi # the ls command directory
>> only has one file(this tool),so the tool's buffer 80x25*4 won't overflow.
>>
>>
>> #test-2
>> run smalltest.efi,
>> just key in some chars and Enter,nothing output,why?
>>
>>
>> my test environment:
>> UDK2018 + vs2015
>> QEMU emulator version 2.10.95
>> OVMF_X64.fd( x64,release build)
>>
>>
>> the tool's build command:
>> D:\edk2-vUDK2018>build -p ShellPkg\ShellPkg.dsc -m
>> ShellPkg\Application2\smalltest\smalltest.inf -a X64 -b RELEASE
>>
>>
>> //code---smalltest.c-
>>
>>
>> #include
>> #include
>> #include
>> #include //global gST gBS gImageHandle
>> #include
>> #include
>>
>>
>> #include
>> #include
>>
>>
>>
>> EFI_STATUS
>> EFIAPI
>> UefiMain (
>> IN EFI_HANDLE ImageHandle,
>> IN EFI_SYSTEM_TABLE *SystemTable
>> )
>> {
>> EFI_STATUS status;
>> EFI_SHELL_PROTOCOL* gShell;
>> EFI_SHELL_PARAMETERS_PROTOCOL*gParameters;
>> UINT16 Buffer[80*25*4]; //tool's buffer;
>> UINTN BufferSize=sizeof(Buffer);
>> UINTN BufferByteSize=BufferSize*sizeof(UINT16);
>>
>>
>> status=gBS->HandleProtocol(gImageHandle,&gEfiShellParametersProtocolGuid,&gParameters);
>> if(status!=EFI_SUCCESS)
>> {
>> Print(L"locate gEfiShellParametersProtocolGuid failed.\n");
>> return status;
>> }
>>
>>
>> status=gBS->LocateProtocol(&gEfiShellProtocolGuid,NULL,&gShell);
>> if(status!=EFI_SUCCESS)
>> {
>> Print(L"locate gEfiShellProtocolGuid failed.\n");
>> return status;
>> }
>>
>>
>> status=gShell->ReadFile(gParameters->StdIn,&BufferByteSize,(VOID*)Buffer);
>> if(status!=EFI_SUCCESS)
>> {
>> Print(L"read from gParameters->StdIn failed.\n");
>> return status;
>> }
>>
>>
>> status=gShell->WriteFile(gParameters->StdOut,&BufferByteSize,(VOID*)Buffer);
>> if(status!=EFI_SUCCESS)
>> {
>> Print(L"wirte gParameters->StdOut failed\n");
>> return status;
>> }
>>
>>
>> gShell->FlushFile(gParameters->StdOut);
>>
>>
>> return EFI_SUCCESS;
>> }
>>
>>
>> //code---smalltest.inf-
>>
>>
>> [Defines]
>> INF_VERSION= 0x00010005
>> BASE_NAME = smalltest
>> FILE_GUID = 8F7D7B1D-0E1C-4c98-B12E-4EC99C400704
>> MODULE_TYPE= UEFI_APPLICATION
>> VERSION_STRING = 1.0
>> ENTRY_POINT= UefiMain
>>
>>
>> [Sources]
>> smalltest.c
>>
>>
>> [Packages]
>> MdePkg/MdePkg.dec
>>
>>
>> [Protocols]
>> gEfiShellProtocolGuid
>> gEfiShellParametersProtocolGuid
>>
>>
>> [LibraryClasses]
>> UefiApplicationEntryPoint
>> UefiLib
>> //code---end--
>>
>>
>>
>>
>>
>>
>> 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
[edk2] question about uefi shell pipe.
Hi,
I wrote this shell application(smalltest.efi),did some pipe function test,find
some strange result.
boot into shell:
# test-1,the follow two command should has the same output ,but infact not the
same in QEMU,and the second command failed WriteFile in real machine(AMI bios
uefi 2.6):
ls | smalltest.efi
ls | smalltest.efi | smalltest.efi # the ls command directory only
has one file(this tool),so the tool's buffer 80x25*4 won't overflow.
#test-2
run smalltest.efi,
just key in some chars and Enter,nothing output,why?
my test environment:
UDK2018 + vs2015
QEMU emulator version 2.10.95
OVMF_X64.fd( x64,release build)
the tool's build command:
D:\edk2-vUDK2018>build -p ShellPkg\ShellPkg.dsc -m
ShellPkg\Application2\smalltest\smalltest.inf -a X64 -b RELEASE
//code---smalltest.c-
#include
#include
#include
#include //global gST gBS gImageHandle
#include
#include
#include
#include
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS status;
EFI_SHELL_PROTOCOL* gShell;
EFI_SHELL_PARAMETERS_PROTOCOL*gParameters;
UINT16 Buffer[80*25*4]; //tool's buffer;
UINTN BufferSize=sizeof(Buffer);
UINTN BufferByteSize=BufferSize*sizeof(UINT16);
status=gBS->HandleProtocol(gImageHandle,&gEfiShellParametersProtocolGuid,&gParameters);
if(status!=EFI_SUCCESS)
{
Print(L"locate gEfiShellParametersProtocolGuid failed.\n");
return status;
}
status=gBS->LocateProtocol(&gEfiShellProtocolGuid,NULL,&gShell);
if(status!=EFI_SUCCESS)
{
Print(L"locate gEfiShellProtocolGuid failed.\n");
return status;
}
status=gShell->ReadFile(gParameters->StdIn,&BufferByteSize,(VOID*)Buffer);
if(status!=EFI_SUCCESS)
{
Print(L"read from gParameters->StdIn failed.\n");
return status;
}
status=gShell->WriteFile(gParameters->StdOut,&BufferByteSize,(VOID*)Buffer);
if(status!=EFI_SUCCESS)
{
Print(L"wirte gParameters->StdOut failed\n");
return status;
}
gShell->FlushFile(gParameters->StdOut);
return EFI_SUCCESS;
}
//code---smalltest.inf-
[Defines]
INF_VERSION= 0x00010005
BASE_NAME = smalltest
FILE_GUID = 8F7D7B1D-0E1C-4c98-B12E-4EC99C400704
MODULE_TYPE= UEFI_APPLICATION
VERSION_STRING = 1.0
ENTRY_POINT= UefiMain
[Sources]
smalltest.c
[Packages]
MdePkg/MdePkg.dec
[Protocols]
gEfiShellProtocolGuid
gEfiShellParametersProtocolGuid
[LibraryClasses]
UefiApplicationEntryPoint
UefiLib
//code---end--
thank you,
by krishna.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [EDK2][UEFI_Shell_Specification_2.2]the fs-dirs define may be not accurate.
Hi, Recently,I want to exactly know what is filepath/filename,I come across this specification, Follow information come from UEFI_Shell_2.2.pdf, 3.7 File Names fs-path := [fs-map-name] [fs-divider][fs-dirs][fs-name] fs-map-name := identifier : fs-divider:= \ | / fs-dirs := fs-dir | fs-dirs fs-dir fs-dir := fs-name fs-divider fs-name := fs-file-name .fs-file-ext fs-file-name := one or more ASCII characters, excluding * ? < > \ / ” : ) #I want to say follow example is a fs-dirs,relatively; fo\foo\ #but follow example is also a fs-dirs,absolutely; FS0:\fo\foo\ #so the define should be: fs-dirs-absolute := fs-map-name fs-divider | fs-map-name fs-divider fs-dirs-relative fs-dirs-relative := fs-dir | fs-dirs-relative fs-dir fs-dir := fs-name fs-divider #is that right? thanks by krishna ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [EDK2]How to do source level debug (OVMF & QEMU & Intel UEFI Development Debugger Tool)
Hi everyone, I know nothing about this source level debug mode so I had read some articles and tried to make this environment,but failed. I do this as I want to observe how SEC phase jump to PEI phase. #1 build ovmf: build -p OvmfPkg/OvmfPkgIa32.dsc -a IA32 -D DEBUG_ON_SERIAL_PORT -D SOURCE_DEBUG_ENABLE #2 run it alone,ok qemu-system-x86_64.exe -machine pc-q35-2.9 -pflash OVMF32-source-debug.fd -serial stdio #3 redirect serial to tcp,it hints "info: QEMU waiting for connection on: disconnected:tcp:::1:1234,server" qemu-system-x86_64.exe -machine pc-q35-2.9 -pflash OVMF32_source_debug.fd -serial tcp:localhost:1234,server #4,execute "C:\Program Files (x86)\Intel\Intel(R) UEFI Development Kit Debugger Tool\eXdi.exe" /LaunchWinDbg" with follow settings,but failed connect to qemu. # error message box"Unable to open TCP address(localhost:1234):No connection could be made because the target machine actively refused it" [Debug Port] Channel = TCP Server = localhost Port = 1234 I also tried using pipe and com port, all can't connect to qemu,it is very appreciate if anyone could give any baby steps... # other information: my windows:win10 x64 QEMU version:2.10 UDK2017 Microsoft (R) Windows Debugger Version 6.12.0002.633 X86(install by default settings) Intel UEFI Development Debugger Tool 1.5(install by default settings) thank you by krishna ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Why the DEBUG can't output the full string?
Hi Laszlo Ersek and Andrew Fish,
I had change all the MACRO in MdePkg + MdeModulePkg like this "#define
MAX_DEBUG_MESSAGE_LENGTH 0x1000",and it has no function;
I had also change follow MACRO value from 200 to 1000:
//
D:\edk2-vUDK2017\MdeModulePkg\Include\Guid\StatusCodeDataTypeDebug.h
///
/// The maximum size of an EFI_DEBUG_INFO structure.
///
#define EFI_STATUS_CODE_DATA_MAX_SIZE 1000
//
I had clean and rebuild the project Nt32Pkg and follow test.
then the debug char's length is extended ok,This behave looks strange...
//test code:
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
CHAR16
buffer[]=L"-A0-11-aa-bb-cc-dd-ee-ff-gg\
--B0-11-aa-bb-cc-dd-ee-ff-gg";
CHAR16
buffer2[]=L"-C0-11-aa-bb-cc-dd-ee-ff-gg\
--D0-11-aa-bb-cc-dd-ee-ff-gg-";
DEBUG ((EFI_D_INFO,"size-of-buffer:%d\n",sizeof(buffer)));
DEBUG ((EFI_D_INFO,"%s",buffer));
DEBUG ((EFI_D_INFO,"\r\n"));
DEBUG ((EFI_D_INFO,"%s",buffer2));
DEBUG ((EFI_D_INFO,"\r\n"));
return EFI_SUCCESS;
}
//test code end;
I don't know if it is a bug,nevertheless,it worked as I expect.
thank you.
by krishna.
At 2018-02-02 10:07:14, "krishnaLee" wrote:
Hi Andrew Fish,
I didn't know the internal buffer is limited, I just think the Hii
will be a formatted string,I want to understarnd how it worked
so I print it,I find the result is not as I expected...
I had calculate the first DEBUG string length,it is 199 chars limited.then I
search the MdePkg+MdeModulePkg for the define "MAX_DEBUG_MESSAGE_LENGTH",and
modify them all to"#define MAX_DEBUG_MESSAGE_LENGTH 0x200",
rebuild Nt32Pkg,run my test,but the result is same,it is still 199 chars
limited.
thanks.
At 2018-02-02 03:21:06, "Andrew Fish" wrote:
On Feb 1, 2018, at 8:23 AM, Laszlo Ersek wrote:
On 02/01/18 10:47, krishnaLee wrote:
Hi,
For example,the follow code:
//-code-start
ConfigRequestHdr = HiiConstructConfigHdr (&mBlankDrvFormSetGuid, VariableName,
PrivateData1->DriverHandle[0]);
Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
ConfigRequest = AllocateZeroPool (Size);
ASSERT (ConfigRequest != NULL);
AllocatedRequest = TRUE;
UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX",
ConfigRequestHdr, (UINT64)BufferSize);
FreePool (ConfigRequestHdr);
//-code-end
I add a debug message at the end of code:
DEBUG((EFI_D_INFO,"construct-ConfigRequest:%s",ConfigRequest));
DEBUG((EFI_D_INFO,"\r\n"));
and the output will be:
construct-ConfigRequest:GUID=db3b005aa15068459170ebd49e16c47c&NAME=00420044004d0079004900660072004e00560044006100740061&PATH=01041400db3b005aa15068459170ebd49e16c47c7fff0400&OFFSET=0&WIDTH=00
If I add another debug message at the end of code:
DEBUG((EFI_D_INFO,"construct-ConfigRequest:"));
for(UINTN i=0;ihttps://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Why the DEBUG can't output the full string?
Hi Andrew Fish, I didn't know the internal buffer is limited, I just think the Hii will be a formatted string,I want to understarnd how it worked so I print it,I find the result is not as I expected... I had calculate the first DEBUG string length,it is 199 chars limited.then I search the MdePkg+MdeModulePkg for the define "MAX_DEBUG_MESSAGE_LENGTH",and modify them all to"#define MAX_DEBUG_MESSAGE_LENGTH 0x200", rebuild Nt32Pkg,run my test,but the result is same,it is still 199 chars limited. thanks. At 2018-02-02 03:21:06, "Andrew Fish" wrote: On Feb 1, 2018, at 8:23 AM, Laszlo Ersek wrote: On 02/01/18 10:47, krishnaLee wrote: Hi, For example,the follow code: //-code-start ConfigRequestHdr = HiiConstructConfigHdr (&mBlankDrvFormSetGuid, VariableName, PrivateData1->DriverHandle[0]); Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16); ConfigRequest = AllocateZeroPool (Size); ASSERT (ConfigRequest != NULL); AllocatedRequest = TRUE; UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX", ConfigRequestHdr, (UINT64)BufferSize); FreePool (ConfigRequestHdr); //-code-end I add a debug message at the end of code: DEBUG((EFI_D_INFO,"construct-ConfigRequest:%s",ConfigRequest)); DEBUG((EFI_D_INFO,"\r\n")); and the output will be: construct-ConfigRequest:GUID=db3b005aa15068459170ebd49e16c47c&NAME=00420044004d0079004900660072004e00560044006100740061&PATH=01041400db3b005aa15068459170ebd49e16c47c7fff0400&OFFSET=0&WIDTH=00 If I add another debug message at the end of code: DEBUG((EFI_D_INFO,"construct-ConfigRequest:")); for(UINTN i=0;ihttps://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Why the DEBUG can't output the full string?
Hi, For example,the follow code: //-code-start ConfigRequestHdr = HiiConstructConfigHdr (&mBlankDrvFormSetGuid, VariableName, PrivateData1->DriverHandle[0]); Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16); ConfigRequest = AllocateZeroPool (Size); ASSERT (ConfigRequest != NULL); AllocatedRequest = TRUE; UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX", ConfigRequestHdr, (UINT64)BufferSize); FreePool (ConfigRequestHdr); //-code-end I add a debug message at the end of code: DEBUG((EFI_D_INFO,"construct-ConfigRequest:%s",ConfigRequest)); DEBUG((EFI_D_INFO,"\r\n")); and the output will be: construct-ConfigRequest:GUID=db3b005aa15068459170ebd49e16c47c&NAME=00420044004d0079004900660072004e00560044006100740061&PATH=01041400db3b005aa15068459170ebd49e16c47c7fff0400&OFFSET=0&WIDTH=00 If I add another debug message at the end of code: DEBUG((EFI_D_INFO,"construct-ConfigRequest:")); for(UINTN i=0;i___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Need help about a Hii tutorial.
Hi, I am learning Hii and I know few about Hii,luckly,I found a good tutorial here: https://firmware.intel.com/sites/default/files/Lab_Material_FW.zip source_code locate in:Lab_Material_FW.zip\FW\LabSampleCode\MyWizardDriver https://firmware.intel.com/sites/default/files/Presentations161017.zip Hii-tutorial locate in:Presentations161017.zip\FW\Presentations\_UEFI_Lab_Guide .docx,--> chapter 9.1 So I follow the chapter9.1, when I compile and build run,I find a entry at bios setup->Device Manager->My Wizard Driver Sample Formset,ok, so I select it and press Enter,Error happened: ASSERT!: [HiiDatabase] d:\edk2-vudk2017\MdePkg\Library\BaseLib\String.c (172): String != ((void *) 0) I had tried more then 5 times form start to end,same failure. I find the checkbox can't work, if I disable the VFR-file's checkbox and add a text,it worked: //working VFR: form formid = 1, title = STRING_TOKEN(STR_SAMPLE_FORM1_TITLE); subtitle text = STRING_TOKEN(STR_SUBTITLE_TEXT); subtitle text = STRING_TOKEN(STR_SUBTITLE_TEXT2); // Define a checkbox to enable / disable the device checkbox varid = MWD_IfrNVData.MyWizardDriverChooseToEnable, // prompt = STRING_TOKEN(STR_CHECK_BOX_PROMPT), // help = STRING_TOKEN(STR_CHECK_BOX_HELP), // flags= CHECKBOX_DEFAULT , // key = 0, // default = 1, // endcheckbox; text help = STRING_TOKEN(STR_CHECK_BOX_PROMPT), text = STRING_TOKEN(STR_CHECK_BOX_HELP), text = STRING_TOKEN(STR_CHECK_BOX_HELP), flags = 0, key= 0; endform; endformset; I think the tutorial has a bug,I don't how to contuine,some help will be great appreciate. my platform:windows 10 x64+UDK2017+VS2015 by krishna ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Communicate with soft-smi-handler with uefi-application question.
Hi,Star:
Yes,that's what I needed,now I understand the buffer has some restriction.
thank you very much!
by krishna
At 2018-01-10 17:26:28, "Zeng, Star" wrote:
>The trusted smm communication buffer needs to be allocated as
>EfiReservedMemoryType, EfiACPIMemoryNVS, or EfiRuntimeServicesData before
>EndOfDxe.
>There is a generic smm communication buffer can be used if
>MdeModulePkg\Universal\SmmCommunicationBufferDxe is included in dsc and fdf.
>
>You can refer
>https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.c#L90
> to know how it be used.
>
>
>Thanks,
>Star
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>krishnaLee
>Sent: Wednesday, January 10, 2018 3:44 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] Communicate with soft-smi-handler with uefi-application
>question.
>
>Hi,
>I'm learning to write and register some soft-Smi-Handler in smm-mode; then
>using QEMU to boot my ovmf.fd,run into uefi shell; then write uefi-application
>using EFI_SMM_COMMUNICATION_PROTOCOL to Communicate to my Smi-Handler,but
>failed when run my uefi-application,the log show error.
>I don't know why,maybe I do not full understand uefi-smm,but how to
>communicate to my smi handler?
>
>
>//error-message
>[Security] 3rd party image[0] can be loaded after EndOfDxe:
>PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x,0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)/\mytestsmm.efi.
>InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 65FC4A8 Loading
>driver at 0x62B EntryPoint=0x62B10F5 mytestsmm.efi
>InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 65FCB10
>ProtectUefiImageCommon - 0x65FC4A8
> - 0x062B - 0x7000
>InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 7700CFC
>InstallProtocolInterface: 4C8A2451-C207-405B-9694-99EA13251341 62B40B0 Locate
>EfiSmmCommunicationProtocol success
>SmmIsBufferOutsideSmmValid: Not in ValidCommunicationRegion: Buffer
>(0x7700C94) - Length (0x2A), ASSERT [PiSmmCore]
>d:\edk2-vudk2017\MdePkg\Library\SmmMemLib\SmmMemLib.c(178): ((BOOLEAN)(0==1))
>//error-message-end
>
>
>//my register-smi-handler code:
>//edk2-vUDK2017\MdeModulePkg\Universal\LockBox\SmmLockBox\SmmLockBox.c
>
>EFI_STATUS
>
>EFIAPI
>
>MyTestSmmHandler (
>
>IN EFI_HANDLE DispatchHandle,
>
>IN CONST VOID *Context OPTIONAL,
>
>IN OUT VOID *CommBuffer OPTIONAL,
>
>IN OUT UINTN *CommBufferSize OPTIONAL
>
>)
>
>{
>
>DEBUG ((DEBUG_INFO, "My Test Smm Handler Enter\n"));
>
>DEBUG ((DEBUG_INFO, "My Test Smm Handler exit\n"));
>
>return EFI_SUCCESS;
>
>}
>
>
>
>
>EFI_STATUS
>
>EFIAPI
>
>SmmLockBoxEntryPoint (
>
>IN EFI_HANDLE ImageHandle,
>
>IN EFI_SYSTEM_TABLE *SystemTable
>
>)
>
>{...
>
>//Register My Test Smm handler
>
>Status = gSmst->SmiHandlerRegister (
>
>MyTestSmmHandler,
>
>&gEfiMyTestSmmGuid,
>
>&DispatchHandle
>
>);
>
>ASSERT_EFI_ERROR (Status);
>
>...
>
>}
>
>
>
>//the uefi-application code
>EFI_STATUS
>EFIAPI
>UefiMain (
>IN EFI_HANDLE ImageHandle,
>IN EFI_SYSTEM_TABLE *SystemTable
>)
>{
>EFI_STATUS Status;
>EFI_SMM_COMMUNICATION_PROTOCOL *mSmmCommunication; EFI_SMM_COMMUNICATE_HEADER
>*SmmCommunicateHeader;
>UINT8 *buffer;
>UINTN bufferSize;
>
>
>bufferSize=sizeof(EFI_SMM_COMMUNICATE_HEADER)*2;
>gBS->AllocatePool (EfiRuntimeServicesData,bufferSize,&buffer);
>if(buffer==NULL)
>{
>Print(L"EFI_OUT_OF_RESOURCES, return\n"); return EFI_OUT_OF_RESOURCES; }
>
>
>SmmCommunicateHeader=(EFI_SMM_COMMUNICATE_HEADER*)buffer;
>CopyGuid(&SmmCommunicateHeader->HeaderGuid,&gEfiMyTestSmmGuid);
>SmmCommunicateHeader->MessageLength=sizeof(EFI_SMM_COMMUNICATE_HEADER);
>
>
>Status = gBS->LocateProtocol (&gEfiSmmCommunicationProtocolGuid, NULL, (VOID
>**) &mSmmCommunication);
>if(Status==EFI_SUCCESS)
>{
>Print(L"Locate EfiSmmCommunicationProtocol success\n"); }else { Print(L"Locate
>EfiSmmCommunicationProtocol failed return\n"); return EFI_SUCCESS; }
>
>
>Status=mSmmCommunication->Communicate(mSmmCommunication,&buffer,&bufferSize);
>if(Status==EFI_SUCCESS)
>{
>Print(L"Communication success\n");
>}else
>{
>Print(L"Communication failed\n");
>return EFI_SUCCESS;
>}
>
>
>gBS->FreePool(buffer);
>
>
>return EFI_SUCCESS;
>}
>
>
>any help will be appreciated!
>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
[edk2] Communicate with soft-smi-handler with uefi-application question.
Hi,
I'm learning to write and register some soft-Smi-Handler in smm-mode;
then using QEMU to boot my ovmf.fd,run into uefi shell;
then write uefi-application using EFI_SMM_COMMUNICATION_PROTOCOL to Communicate
to my Smi-Handler,but failed when run my uefi-application,the log show error.
I don't know why,maybe I do not full understand uefi-smm,but how to communicate
to my smi handler?
//error-message
[Security] 3rd party image[0] can be loaded after EndOfDxe:
PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x,0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)/\mytestsmm.efi.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 65FC4A8
Loading driver at 0x62B EntryPoint=0x62B10F5 mytestsmm.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 65FCB10
ProtectUefiImageCommon - 0x65FC4A8
- 0x062B - 0x7000
InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 7700CFC
InstallProtocolInterface: 4C8A2451-C207-405B-9694-99EA13251341 62B40B0
Locate EfiSmmCommunicationProtocol success
SmmIsBufferOutsideSmmValid: Not in ValidCommunicationRegion: Buffer (0x7700C94)
- Length (0x2A), ASSERT [PiSmmCore]
d:\edk2-vudk2017\MdePkg\Library\SmmMemLib\SmmMemLib.c(178): ((BOOLEAN)(0==1))
//error-message-end
//my register-smi-handler code:
//edk2-vUDK2017\MdeModulePkg\Universal\LockBox\SmmLockBox\SmmLockBox.c
EFI_STATUS
EFIAPI
MyTestSmmHandler (
IN EFI_HANDLE DispatchHandle,
IN CONST VOID *Context OPTIONAL,
IN OUT VOID *CommBuffer OPTIONAL,
IN OUT UINTN *CommBufferSize OPTIONAL
)
{
DEBUG ((DEBUG_INFO, "My Test Smm Handler Enter\n"));
DEBUG ((DEBUG_INFO, "My Test Smm Handler exit\n"));
return EFI_SUCCESS;
}
EFI_STATUS
EFIAPI
SmmLockBoxEntryPoint (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{…
//Register My Test Smm handler
Status = gSmst->SmiHandlerRegister (
MyTestSmmHandler,
&gEfiMyTestSmmGuid,
&DispatchHandle
);
ASSERT_EFI_ERROR (Status);
…
}
//the uefi-application code
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS Status;
EFI_SMM_COMMUNICATION_PROTOCOL *mSmmCommunication;
EFI_SMM_COMMUNICATE_HEADER *SmmCommunicateHeader;
UINT8 *buffer;
UINTN bufferSize;
bufferSize=sizeof(EFI_SMM_COMMUNICATE_HEADER)*2;
gBS->AllocatePool (EfiRuntimeServicesData,bufferSize,&buffer);
if(buffer==NULL)
{
Print(L"EFI_OUT_OF_RESOURCES, return\n");
return EFI_OUT_OF_RESOURCES;
}
SmmCommunicateHeader=(EFI_SMM_COMMUNICATE_HEADER*)buffer;
CopyGuid(&SmmCommunicateHeader->HeaderGuid,&gEfiMyTestSmmGuid);
SmmCommunicateHeader->MessageLength=sizeof(EFI_SMM_COMMUNICATE_HEADER);
Status = gBS->LocateProtocol (&gEfiSmmCommunicationProtocolGuid, NULL, (VOID
**) &mSmmCommunication);
if(Status==EFI_SUCCESS)
{
Print(L"Locate EfiSmmCommunicationProtocol success\n");
}else
{
Print(L"Locate EfiSmmCommunicationProtocol failed return\n");
return EFI_SUCCESS;
}
Status=mSmmCommunication->Communicate(mSmmCommunication,&buffer,&bufferSize);
if(Status==EFI_SUCCESS)
{
Print(L"Communication success\n");
}else
{
Print(L"Communication failed\n");
return EFI_SUCCESS;
}
gBS->FreePool(buffer);
return EFI_SUCCESS;
}
any help will be appreciated!
by krishna
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] How to using PcdGetEx to change a PCD.
Yes, I had tried pass,I think using non-Ex-Pcd will enougth at most of time, the ExPcd is not a good idea. thank you!. 1,DynamicEx PCD is defined in DEC [PcdsDynamicEx] 2, referenced in DSC [PcdsDynamicExDefault] 3,listed in driver's inf [PcdEx] 4,using format PcdGetEx16(&gEfiMdePkgTokenSpaceGuid,myExPcdSample); //do not need the PcdToken(),to wrap myExPcdSample; 在 2017-12-29 23:26:41，"Gao, Liming" 写道： The message shows this PCD is configured as DynamicHii in DSC. For DynamicEx PCD, it should be defined in DEC [PcdsDynamicEx] section. It is set in DSC [PcdsDynamicExDefault] or [PcdsDynamicExHii] section. From: krishnaLee [mailto:sssky...@163.com] Sent: Thursday, December 28, 2017 5:42 PM To: Gao, Liming Cc: Andrew Fish ; edk2-devel@lists.01.org Subject: Re:[edk2] How to using PcdGetEx to change a PCD. Hi,Liming and Andrew Fish, I modified as your description,and move the pcd to [PcdEx] in inf file,but compile fail,the error is type-Mismatched,I understand now,so this pcd is not Ex-Pcd. As Andrew Fish said:"If different binaries that got compiled in different places need to work together then the Ex form is required." Does it mean ,for example ,the bios_rom will finally contaion both Ex and non_Ex PCDs,and PCD_driver will publish the interface to access,so other module for exameple a efi_application access Pcds can using PcdGetEx function to access pcds(type must be DynamicEx )? I can't find a example for PcdGetEx in the EDK2 project,so I think the steps to using it as follow,right? 1,define a DynamicEx PCD in MdePkg.dec,format as follow，the follow token-number:0x00f1 ,just a unique number will work well ,yes? [PcdsDynamicEx] gEfiMdePkgTokenSpaceGuid.myExPcdSample| 0xE000 |UINT64 | 0x00f1 2,reference and modify it in Nt32Pkg.dsc as follow: [PcdsDynamicEx] gEfiMdePkgTokenSpaceGuid.myExPcdSample| 0xD000 # value changed for the platform. 3,using the pcd in some drivers by PcdGetEx function,the driver can modifiy it in runtime ,the driver must build in Nt32Pkg.dsc, the driver must build in bios.fd. 3-1,add follow to driver-inf file: [Guid] gEfiMdePkgTokenSpaceGuid [PcdEx] gEfiMdePkgTokenSpaceGuid.myExPcdSample 3-2,add pcd-library to the driver-module and write code in source.c as follow: #include //pcd need #include //PcdToken ... PcdGetEx64(&gEfiMdePkgTokenSpaceGuid,PcdToken(myExPcdSample)); PcdSetEx64(&gEfiMdePkgTokenSpaceGuid,PcdToken(myExPcdSample),some_value_changed); 4,using the pcd in uefi_Shell_application by PcdGetEx function,to check the runtime-value.the flow is same as driver. //steps-end //last build-error-message: build... d:\edk2-vudk2017\Nt32Pkg\Nt32Pkg.dsc(...): error 1002: Mismatched PCD type gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut is defined as [DynamicEx] in module d:\edk2-vudk2017\Nt32Pkg\Application\mytestpcd2\mytestpcd2.inf, but as [DynamicHii] in platform. Stop. some edk2 mail has sorted to a wrong group by me,so I haven't see it for a long time,sorry to reply late. thank you by krishna At 2017-12-14 22:55:00, "Gao, Liming" wrote: >PcdGet() is the recommended API to be used. It will be mapped to the matched >PcdGet usage based on PCD type. > >PcdGetEx() is only used when PCD is configured to DynamicEx type. Its first >parameter is the pointer to the token space guid, the second parameter is the >token number. The token number can be get by PcdToken() macro. So, the correct >way is PcdGetEx16(&gEfiMdePkgTokenSpaceGuid, PcdToken >(PcdPlatformBootTimeOut));. But PcdPlatformBootTimeOut is not configured to >DynamicEx PCD in NT32 platform. This style can pass build, but can't work. > >Thanks >Liming >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Andrew Fish >> Sent: Thursday, December 14, 2017 6:27 PM >> To: krishnaLee >> Cc: edk2-devel@lists.01.org >> Subject: Re: [edk2] How to using PcdGetEx to change a PCD. >> >> >> >> > On Dec 14, 2017, at 12:59 AM, krishnaLee wrote: >> > >> > Hello, >> > I am learning and writing a application to change the Nt32pkg-virtual >> > machine's boot time.follow code is success. >> > but I think if I using PcdGetEx16 function, it will also work well,but >> > failed when I compile it. >> > I had read some Specs about the difference between PcdGetEx and PcdGet,but >> > I can't understand,maybe I need some practice, >> > So can anyone modify it to using PcdGetEx to implement the same function >> > in the application? >> > //source-code--start >> >> Did you add: >> >> #include >> >> and
Re: [edk2] How to using PcdGetEx to change a PCD.
Hi,Liming and Andrew Fish, I modified as your description,and move the pcd to [PcdEx] in inf file,but compile fail,the error is type-Mismatched,I understand now,so this pcd is not Ex-Pcd. As Andrew Fish said:"If different binaries that got compiled in different places need to work together then the Ex form is required." Does it mean ,for example ,the bios_rom will finally contaion both Ex and non_Ex PCDs,and PCD_driver will publish the interface to access,so other module for exameple a efi_application access Pcds can using PcdGetEx function to access pcds(type must be DynamicEx )? I can't find a example for PcdGetEx in the EDK2 project,so I think the steps to using it as follow,right? 1,define a DynamicEx PCD in MdePkg.dec,format as follow，the follow token-number:0x00f1 ,just a unique number will work well ,yes? [PcdsDynamicEx] gEfiMdePkgTokenSpaceGuid.myExPcdSample| 0xE000 |UINT64 | 0x00f1 2,reference and modify it in Nt32Pkg.dsc as follow: [PcdsDynamicEx] gEfiMdePkgTokenSpaceGuid.myExPcdSample| 0xD000 # value changed for the platform. 3,using the pcd in some drivers by PcdGetEx function,the driver can modifiy it in runtime ,the driver must build in Nt32Pkg.dsc, the driver must build in bios.fd. 3-1,add follow to driver-inf file: [Guid] gEfiMdePkgTokenSpaceGuid [PcdEx] gEfiMdePkgTokenSpaceGuid.myExPcdSample 3-2,add pcd-library to the driver-module and write code in source.c as follow: #include //pcd need #include //PcdToken ... PcdGetEx64(&gEfiMdePkgTokenSpaceGuid,PcdToken(myExPcdSample)); PcdSetEx64(&gEfiMdePkgTokenSpaceGuid,PcdToken(myExPcdSample),some_value_changed); 4,using the pcd in uefi_Shell_application by PcdGetEx function,to check the runtime-value.the flow is same as driver. //steps-end //last build-error-message: build... d:\edk2-vudk2017\Nt32Pkg\Nt32Pkg.dsc(...): error 1002: Mismatched PCD type gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut is defined as [DynamicEx] in module d:\edk2-vudk2017\Nt32Pkg\Application\mytestpcd2\mytestpcd2.inf, but as [DynamicHii] in platform. Stop. some edk2 mail has sorted to a wrong group by me,so I haven't see it for a long time,sorry to reply late. thank you by krishna At 2017-12-14 22:55:00, "Gao, Liming" wrote: >PcdGet() is the recommended API to be used. It will be mapped to the matched >PcdGet usage based on PCD type. > >PcdGetEx() is only used when PCD is configured to DynamicEx type. Its first >parameter is the pointer to the token space guid, the second parameter is the >token number. The token number can be get by PcdToken() macro. So, the correct >way is PcdGetEx16(&gEfiMdePkgTokenSpaceGuid, PcdToken >(PcdPlatformBootTimeOut));. But PcdPlatformBootTimeOut is not configured to >DynamicEx PCD in NT32 platform. This style can pass build, but can't work. > >Thanks >Liming >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Andrew Fish >> Sent: Thursday, December 14, 2017 6:27 PM >> To: krishnaLee >> Cc: edk2-devel@lists.01.org >> Subject: Re: [edk2] How to using PcdGetEx to change a PCD. >> >> >> >> > On Dec 14, 2017, at 12:59 AM, krishnaLee wrote: >> > >> > Hello, >> > I am learning and writing a application to change the Nt32pkg-virtual >> > machine's boot time.follow code is success. >> > but I think if I using PcdGetEx16 function, it will also work well,but >> > failed when I compile it. >> > I had read some Specs about the difference between PcdGetEx and PcdGet,but >> > I can't understand,maybe I need some practice, >> > So can anyone modify it to using PcdGetEx to implement the same function >> > in the application? >> > //source-code--start >> >> Did you add: >> >> #include >> >> and list gEfiMdePkgTokenSpaceGuid in the [Guids] section of the INF. >> >> In general it is hard to comment on compiler failures in fragments of code. >> If you post the actual compiler error it is easier to explain. >> >> >> >> The PCDs are a GUID + token number namespace for config. Since anyone can >> define a GUID that does not conflict it allows arbitrary >> extension without conflict. >> >> The Ex form of the API includes the GUID + token number. The non Ex form is >> a size optimization that uses a build generated token >> space. So generally if everything is built together then you use the non Ex >> form to save space. If different binaries that got compiled in >> different places need to work together then the Ex form is required. >> >> Thanks, >> >> Andrew Fish >> >
[edk2] How to using PcdGetEx to change a PCD.
Hello,
I am learning and writing a application to change the Nt32pkg-virtual machine's
boot time.follow code is success.
but I think if I using PcdGetEx16 function, it will also work well,but failed
when I compile it.
I had read some Specs about the difference between PcdGetEx and PcdGet,but I
can't understand,maybe I need some practice,
So can anyone modify it to using PcdGetEx to implement the same function in the
application?
//source-code--start
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
UINTN buffer=0;
UINTN index;
buffer=PcdGet16(PcdPlatformBootTimeOut);
//buffer=PcdGetEx16(&gEfiMdePkgTokenSpaceGuid,PcdPlatformBootTimeOut);//compile
failed.
Print(L"buffer:%d\n",buffer);
PcdSet16(PcdPlatformBootTimeOut,5);
...
//source-code-end.
attachment is the full source code.
edk2-vUDK2017's build command:
build -p Nt32Pkg\Nt32Pkg.dsc -m Nt32Pkg\Application\mytestpcd2\mytestpcd2.inf
thank you very much!
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [edk2-UDK2017] issue about AsciiPrint
Hi All,
This function will output nothing or strange-output in my real Lenovo_Q270
machine, follow is the key point:
//for(UINTN j=0;jSignature);j++)
//{
//output byte by byte,or custom range...,or just some
specified bytes in the string...
//AsciiPrint("%c",j,SignatureStr[j]);
//}
--
I had read the Print function note,but I don't understand its meaning for
ascii string using AsciiPrint, for example:If someone want print a part of
ascii-string byte by byte...,
I am newer to write uefi code,May be I mis-understand it,Can anybody clarify it
,or give the full instruction about AsciiPrint.
type:
%
Print a %%.
c
The argument is a Unicode character. ASCII characters can be printed using
this type too by making sure bits 8..15 of the argument are set to 0.
attachment is the full test code.
my-platform-infomation:
udk2017-vs2015x86
build command:build -p ShellPkg\ShellPkg.dsc -m
ShellPkg\Application\querytable\querytable.inf -a X64 -b RELEASE
uefi shell version 2.2
cpu:Intel (r) G4520 3.6Ghz
mem:Sumsang 16G 2133
motherboard:Lenovo_Q270
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
