Hello everyone
I am trying to invoke the EDK2 shell on Aarch64 SOC.
Here is my shell prompt
[1] Shell [2] Boot Manager Start: 1 add-symbol-file /home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 0x1A831000 Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 Shell.efi UEFI Interactive Shell v2.1 EDK II UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000) Mapping table FS0: Alias(s):F3: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB) No SimpleTextInputEx was found. CTRL-based features are not usable. No SimpleTextInputEx was found. CTRL-based features are not usable. Press ESC in 5 seconds to skip startup.nsh or any other key to continue
From here on any key I press causes call to "GccSemihostCall" which invokes a HW breakpoint on AArch64.
I noticed GccSemihostCall doesn't trigger a breakpoint in ARM arch. I am using " SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf"
Do you have any idea why I get to "GccSemihostCall". ? Am I missing something in my system setup. ?
I copied the shell related packages from ArmVirtPkg since I know it works there
Thanks
------------------- Yehuda Yitschak Marvell Semiconductor Ltd.
On 19 November 2015 at 16:25, Yehuda Yitschak yehuday@marvell.com wrote:
Hello everyone
Hello Yehuda,
I am trying to invoke the EDK2 shell on Aarch64 SOC.
Here is my shell prompt
[1] Shell
[2] Boot Manager
Start: 1
First of all, please move to the Intel BDS. The ARM BDS (i.e., this menu system) is not UEFI compliant, and you will not be able to boot OS installers easily if you keep using it. Look at the repo history for ArmVExpress-FVP-AArch64.dsc for hints how to go about this.
add-symbol-file /home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 0x1A831000
Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 Shell.efi
UEFI Interactive Shell v2.1
EDK II
UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000)
Mapping table
FS0: Alias(s):F3: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)No SimpleTextInputEx was found. CTRL-based features are not usable.
No SimpleTextInputEx was found. CTRL-based features are not usable.
Press ESC in 5 seconds to skip startup.nsh or any other key to continue
From here on any key I press causes call to “GccSemihostCall” which invokes a HW breakpoint on AArch64.
I noticed GccSemihostCall doesn’t trigger a breakpoint in ARM arch.
I am using “ SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf”
You don't need this library on bare metal if you are not using a debugger that supports semihosting. So the simple answer is to just remove it from your .DSC and .FDF files.
Do you have any idea why I get to “GccSemihostCall”. ?
Am I missing something in my system setup. ?
The shell tries to load 'startup.nsh' from the semihosting file system, using semihosting specific breakpoint instructions.
I copied the shell related packages from ArmVirtPkg since I know it works there
Yes, that makes sense in itself, since it builds the shell from source rather than use the binary package.
Hi Ard
Thanks for the prompt reply.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Thursday, November 19, 2015 17:31 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 19 November 2015 at 16:25, Yehuda Yitschak yehuday@marvell.com wrote:
Hello everyone
Hello Yehuda,
I am trying to invoke the EDK2 shell on Aarch64 SOC.
Here is my shell prompt
[1] Shell
[2] Boot Manager
Start: 1
First of all, please move to the Intel BDS. The ARM BDS (i.e., this menu system) is not UEFI compliant, and you will not be able to boot OS installers easily if you keep using it. Look at the repo history for ArmVExpress-FVP- AArch64.dsc for hints how to go about this.
I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which one. I will try again using the suggested DSC. thanks
add-symbol-file
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S hellPk
g/Application/Shell/Shell/DEBUG/Shell.dll 0x1A831000
Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 Shell.efi
UEFI Interactive Shell v2.1
EDK II
UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000)
Mapping table
FS0: Alias(s):F3: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)No SimpleTextInputEx was found. CTRL-based features are not usable.
No SimpleTextInputEx was found. CTRL-based features are not usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Press ESC in 5 seconds to skip startup.nsh or any other key to continue
From here on any key I press causes call to “GccSemihostCall” which invokes a HW breakpoint on AArch64.
I noticed GccSemihostCall doesn’t trigger a breakpoint in ARM arch.
I am using “ SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf”
You don't need this library on bare metal if you are not using a debugger that supports semihosting. So the simple answer is to just remove it from your .DSC and .FDF files.
Okay. I just reused "...2nd-level.dsc" and still didn’t filter the unnecessary stuff since frankly I don’t yet understand what most packages do
Do you have any idea why I get to “GccSemihostCall”. ?
Am I missing something in my system setup. ?
The shell tries to load 'startup.nsh' from the semihosting file system, using semihosting specific breakpoint instructions.
That make sense now. I should have mentioned I am connected with a HW debugger so a HLT instruction just stops the execution.
I copied the shell related packages from ArmVirtPkg since I know it works there
Yes, that makes sense in itself, since it builds the shell from source rather than use the binary package.
On 19 November 2015 at 16:42, Yehuda Yitschak yehuday@marvell.com wrote:
Hi Ard
Thanks for the prompt reply.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Thursday, November 19, 2015 17:31 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 19 November 2015 at 16:25, Yehuda Yitschak yehuday@marvell.com wrote:
Hello everyone
Hello Yehuda,
I am trying to invoke the EDK2 shell on Aarch64 SOC.
Here is my shell prompt
[1] Shell
[2] Boot Manager
Start: 1
First of all, please move to the Intel BDS. The ARM BDS (i.e., this menu system) is not UEFI compliant, and you will not be able to boot OS installers easily if you keep using it. Look at the repo history for ArmVExpress-FVP- AArch64.dsc for hints how to go about this.
I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which one. I will try again using the suggested DSC. thanks
add-symbol-file
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S hellPk
g/Application/Shell/Shell/DEBUG/Shell.dll 0x1A831000
Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 Shell.efi
UEFI Interactive Shell v2.1
EDK II
UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000)
Mapping table
FS0: Alias(s):F3: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)No SimpleTextInputEx was found. CTRL-based features are not usable.
No SimpleTextInputEx was found. CTRL-based features are not usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Not a clue, sorry. But I suppose a missing protocol like that could explain the Intel BDS issue as well.
Press ESC in 5 seconds to skip startup.nsh or any other key to continue
From here on any key I press causes call to “GccSemihostCall” which invokes a HW breakpoint on AArch64.
I noticed GccSemihostCall doesn’t trigger a breakpoint in ARM arch.
I am using “ SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf”
You don't need this library on bare metal if you are not using a debugger that supports semihosting. So the simple answer is to just remove it from your .DSC and .FDF files.
Okay. I just reused "...2nd-level.dsc" and still didn’t filter the unnecessary stuff since frankly I don’t yet understand what most packages do
Do you have any idea why I get to “GccSemihostCall”. ?
Am I missing something in my system setup. ?
The shell tries to load 'startup.nsh' from the semihosting file system, using semihosting specific breakpoint instructions.
That make sense now. I should have mentioned I am connected with a HW debugger so a HLT instruction just stops the execution.
I copied the shell related packages from ArmVirtPkg since I know it works there
Yes, that makes sense in itself, since it builds the shell from source rather than use the binary package.
On 11/19/2015 11:51 PM, Ard Biesheuvel wrote:
On 19 November 2015 at 16:42, Yehuda Yitschak yehuday@marvell.com wrote:
Hi Ard
Thanks for the prompt reply.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Thursday, November 19, 2015 17:31 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 19 November 2015 at 16:25, Yehuda Yitschak yehuday@marvell.com wrote:
Hello everyone
Hello Yehuda,
I am trying to invoke the EDK2 shell on Aarch64 SOC.
Here is my shell prompt
[1] Shell
[2] Boot Manager
Start: 1
First of all, please move to the Intel BDS. The ARM BDS (i.e., this menu system) is not UEFI compliant, and you will not be able to boot OS installers easily if you keep using it. Look at the repo history for ArmVExpress-FVP- AArch64.dsc for hints how to go about this.
I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which one. I will try again using the suggested DSC. thanks
add-symbol-file
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S hellPk
g/Application/Shell/Shell/DEBUG/Shell.dll 0x1A831000
Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 Shell.efi
UEFI Interactive Shell v2.1
EDK II
UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000)
Mapping table
FS0: Alias(s):F3: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)No SimpleTextInputEx was found. CTRL-based features are not usable.
No SimpleTextInputEx was found. CTRL-based features are not usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Not a clue, sorry. But I suppose a missing protocol like that could explain the Intel BDS issue as well.
I think you are using EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf as your terminal driver. You can try using below drivers for a more powerful terminal:
INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF EmbeddedPkg/SerialDxe/SerialDxe.inf
Heyi
Press ESC in 5 seconds to skip startup.nsh or any other key to continue
From here on any key I press causes call to “GccSemihostCall” which invokes a HW breakpoint on AArch64.
I noticed GccSemihostCall doesn’t trigger a breakpoint in ARM arch.
I am using “ SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf”
You don't need this library on bare metal if you are not using a debugger that supports semihosting. So the simple answer is to just remove it from your .DSC and .FDF files.
Okay. I just reused "...2nd-level.dsc" and still didn’t filter the unnecessary stuff since frankly I don’t yet understand what most packages do
Do you have any idea why I get to “GccSemihostCall”. ?
Am I missing something in my system setup. ?
The shell tries to load 'startup.nsh' from the semihosting file system, using semihosting specific breakpoint instructions.
That make sense now. I should have mentioned I am connected with a HW debugger so a HLT instruction just stops the execution.
I copied the shell related packages from ArmVirtPkg since I know it works there
Yes, that makes sense in itself, since it builds the shell from source rather than use the binary package.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
On 20 November 2015 at 05:09, Heyi Guo heyi.guo@linaro.org wrote:
On 11/19/2015 11:51 PM, Ard Biesheuvel wrote:
On 19 November 2015 at 16:42, Yehuda Yitschak yehuday@marvell.com wrote:
Hi Ard
Thanks for the prompt reply.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Thursday, November 19, 2015 17:31 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 19 November 2015 at 16:25, Yehuda Yitschak yehuday@marvell.com wrote:
Hello everyone
Hello Yehuda,
I am trying to invoke the EDK2 shell on Aarch64 SOC.
Here is my shell prompt
[1] Shell
[2] Boot Manager
Start: 1
First of all, please move to the Intel BDS. The ARM BDS (i.e., this menu system) is not UEFI compliant, and you will not be able to boot OS installers easily if you keep using it. Look at the repo history for ArmVExpress-FVP- AArch64.dsc for hints how to go about this.
I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which one. I will try again using the suggested DSC. thanks
add-symbol-file
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S hellPk
g/Application/Shell/Shell/DEBUG/Shell.dll 0x1A831000
Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 Shell.efi
UEFI Interactive Shell v2.1
EDK II
UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000)
Mapping table
FS0: Alias(s):F3: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)No SimpleTextInputEx was found. CTRL-based features are not usable.
No SimpleTextInputEx was found. CTRL-based features are not usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Not a clue, sorry. But I suppose a missing protocol like that could explain the Intel BDS issue as well.
I think you are using EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf as your terminal driver.
Yes, I think that might be the reason for that message.
One solution is to implement SimpleTextInputEx in the simple serial terminal, but I don't think it's worth the effort.
You can try using below drivers for a more powerful terminal:
INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF EmbeddedPkg/SerialDxe/SerialDxe.inf
I prefer to call it a more annoying terminal. The graphics console is a complete ugly pain. Eg., using Shell in a graphics console is utter madness if you're on a serial terminal and not a computer monitor as intended. "Help" doesn't even fit on one "screen". It's a mess.
Although I appreciate that IntelBds and GRUB both use it extensively. So in the future, I think it's the only option, unless someone cares to put a sensible interface on those apps. That's unlikely to happen.
Heyi
Press ESC in 5 seconds to skip startup.nsh or any other key to continue
From here on any key I press causes call to “GccSemihostCall” which invokes a HW breakpoint on AArch64.
I noticed GccSemihostCall doesn’t trigger a breakpoint in ARM arch.
I am using “ SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf”
You don't need this library on bare metal if you are not using a debugger that supports semihosting. So the simple answer is to just remove it from your .DSC and .FDF files.
Okay. I just reused "...2nd-level.dsc" and still didn’t filter the unnecessary stuff since frankly I don’t yet understand what most packages do
Do you have any idea why I get to “GccSemihostCall”. ?
Am I missing something in my system setup. ?
The shell tries to load 'startup.nsh' from the semihosting file system, using semihosting specific breakpoint instructions.
That make sense now. I should have mentioned I am connected with a HW debugger so a HLT instruction just stops the execution.
I copied the shell related packages from ArmVirtPkg since I know it works there
Yes, that makes sense in itself, since it builds the shell from source rather than use the binary package.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
Hi Heyi
-----Original Message----- From: Heyi Guo [mailto:heyi.guo@linaro.org] Sent: Friday, November 20, 2015 07:09 To: Ard Biesheuvel; Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 11/19/2015 11:51 PM, Ard Biesheuvel wrote:
On 19 November 2015 at 16:42, Yehuda Yitschak yehuday@marvell.com
wrote:
Hi Ard
Thanks for the prompt reply.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Thursday, November 19, 2015 17:31 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 19 November 2015 at 16:25, Yehuda Yitschak
wrote:
Hello everyone
Hello Yehuda,
I am trying to invoke the EDK2 shell on Aarch64 SOC.
Here is my shell prompt
[1] Shell
[2] Boot Manager
Start: 1
First of all, please move to the Intel BDS. The ARM BDS (i.e., this menu system) is not UEFI compliant, and you will not be able to boot OS installers easily if you keep using it. Look at the repo history for ArmVExpress-FVP- AArch64.dsc for hints how to go about this.
I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which
one.
I will try again using the suggested DSC. thanks
add-symbol-file
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S
hellPk
g/Application/Shell/Shell/DEBUG/Shell.dll 0x1A831000
Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 Shell.efi
UEFI Interactive Shell v2.1
EDK II
UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000)
Mapping table
FS0: Alias(s):F3: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)No SimpleTextInputEx was found. CTRL-based features are not usable.
No SimpleTextInputEx was found. CTRL-based features are not usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Not a clue, sorry. But I suppose a missing protocol like that could explain the Intel BDS issue as well.
I think you are using EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf as your terminal driver. You can try using below drivers for a more powerful terminal:
INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleD xe.inf INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF EmbeddedPkg/SerialDxe/SerialDxe.inf
Heyi
You are right, I am using "EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf"
I switched to Intel BDS and moved to the console implementations above but the terminal simply freezes when the Bds should start. Could it be since I am using a NULL extended serial port " SerialPortExtLib|EmbeddedPkg/Library/SerialPortExtLibNull/SerialPortExtLibNull.inf" ?
I also tried using the Intel BDS with the SimpleTextInOutSerial but the console behaves strange. It prints too many spaces and line feeds I can't get a proper view on the screen. Is this a valid combination at all ?
Press ESC in 5 seconds to skip startup.nsh or any other key to continue
From here on any key I press causes call to “GccSemihostCall” which invokes a HW breakpoint on AArch64.
I noticed GccSemihostCall doesn’t trigger a breakpoint in ARM arch.
I am using “ SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf”
You don't need this library on bare metal if you are not using a debugger that supports semihosting. So the simple answer is to just remove it from your .DSC and .FDF files.
Okay. I just reused "...2nd-level.dsc" and still didn’t filter the unnecessary stuff since frankly I don’t yet understand what most packages do
Do you have any idea why I get to “GccSemihostCall”. ?
Am I missing something in my system setup. ?
The shell tries to load 'startup.nsh' from the semihosting file system, using semihosting specific breakpoint instructions.
That make sense now. I should have mentioned I am connected with a
HW debugger so a HLT instruction just stops the execution.
I copied the shell related packages from ArmVirtPkg since I know it works there
Yes, that makes sense in itself, since it builds the shell from source rather than use the binary package.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
Hi Yehuda,
One possible reason that you cannot input in BDS is of UEFI timer issue; please check your uefi timer can interrupt normally.
And I think the SerialPortExtLib you're using is OK; I'm also using this library instance.
Regards,
Heyi
On 11/22/2015 10:22 PM, Yehuda Yitschak wrote:
Hi Heyi
-----Original Message----- From: Heyi Guo [mailto:heyi.guo@linaro.org] Sent: Friday, November 20, 2015 07:09 To: Ard Biesheuvel; Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 11/19/2015 11:51 PM, Ard Biesheuvel wrote:
On 19 November 2015 at 16:42, Yehuda Yitschak yehuday@marvell.com
wrote:
Hi Ard
Thanks for the prompt reply.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Thursday, November 19, 2015 17:31 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 19 November 2015 at 16:25, Yehuda Yitschak
wrote:
Hello everyone
Hello Yehuda,
I am trying to invoke the EDK2 shell on Aarch64 SOC.
Here is my shell prompt
[1] Shell
[2] Boot Manager
Start: 1
First of all, please move to the Intel BDS. The ARM BDS (i.e., this menu system) is not UEFI compliant, and you will not be able to boot OS installers easily if you keep using it. Look at the repo history for ArmVExpress-FVP- AArch64.dsc for hints how to go about this.
I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which
one.
I will try again using the suggested DSC. thanks
add-symbol-file
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S
hellPk
g/Application/Shell/Shell/DEBUG/Shell.dll 0x1A831000
Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 Shell.efi
UEFI Interactive Shell v2.1
EDK II
UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000)
Mapping table
FS0: Alias(s):F3: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)No SimpleTextInputEx was found. CTRL-based features are not usable.
No SimpleTextInputEx was found. CTRL-based features are not usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Not a clue, sorry. But I suppose a missing protocol like that could explain the Intel BDS issue as well.
I think you are using EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf as your terminal driver. You can try using below drivers for a more powerful terminal:
INFMdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleD xe.inf INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF EmbeddedPkg/SerialDxe/SerialDxe.inf
Heyi
You are right, I am using "EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf"
I switched to Intel BDS and moved to the console implementations above but the terminal simply freezes when the Bds should start. Could it be since I am using a NULL extended serial port " SerialPortExtLib|EmbeddedPkg/Library/SerialPortExtLibNull/SerialPortExtLibNull.inf" ?
I also tried using the Intel BDS with the SimpleTextInOutSerial but the console behaves strange. It prints too many spaces and line feeds I can't get a proper view on the screen. Is this a valid combination at all ?
Press ESC in 5 seconds to skip startup.nsh or any other key to continue
From here on any key I press causes call to “GccSemihostCall” which invokes a HW breakpoint on AArch64.
I noticed GccSemihostCall doesn’t trigger a breakpoint in ARM arch.
I am using “ SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf”
You don't need this library on bare metal if you are not using a debugger that supports semihosting. So the simple answer is to just remove it from your .DSC and .FDF files.
Okay. I just reused "...2nd-level.dsc" and still didn’t filter the unnecessary stuff since frankly I don’t yet understand what most packages do
Do you have any idea why I get to “GccSemihostCall”. ?
Am I missing something in my system setup. ?
The shell tries to load 'startup.nsh' from the semihosting file system, using semihosting specific breakpoint instructions.
That make sense now. I should have mentioned I am connected with a
HW debugger so a HLT instruction just stops the execution.
I copied the shell related packages from ArmVirtPkg since I know it works there
Yes, that makes sense in itself, since it builds the shell from source rather than use the binary package.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
-----Original Message----- From: Heyi Guo [mailto:heyi.guo@linaro.org] Sent: Monday, November 23, 2015 05:43 To: Yehuda Yitschak; Ard Biesheuvel Cc: Linaro-uefi@lists.linaro.org; Ryan Harkin Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
Hi Yehuda,
One possible reason that you cannot input in BDS is of UEFI timer issue; please check your uefi timer can interrupt normally.
I guess the timer is fine since I am able to fully operate the shell when I use ARM BDS and SimpleText The problem starts when I switch to the more powerful console. I don't even see the initial BDS prints The last visible print is : add-symbol-file /home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/MdeModulePkg/Universal/Disk/Uni codeCollation/EnglishDxe/EnglishDxe/DEBUG/EnglishDxe.dll 0x1F83E240 Loading driver at 0x0001F83E000 EntryPoint=0x0001F83E280 EnglishDxe.efi
All other console DXEs are loaded before so I guess the problem start when DXE switches to BDS.
And I think the SerialPortExtLib you're using is OK; I'm also using this library instance.
Regards,
Heyi
On 11/22/2015 10:22 PM, Yehuda Yitschak wrote:
Hi Heyi
-----Original Message----- From: Heyi Guo [mailto:heyi.guo@linaro.org] Sent: Friday, November 20, 2015 07:09 To: Ard Biesheuvel; Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 11/19/2015 11:51 PM, Ard Biesheuvel wrote:
On 19 November 2015 at 16:42, Yehuda Yitschak
wrote:
Hi Ard
Thanks for the prompt reply.
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Thursday, November 19, 2015 17:31 To: Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 19 November 2015 at 16:25, Yehuda Yitschak
wrote: > Hello everyone > Hello Yehuda,
> I am trying to invoke the EDK2 shell on Aarch64 SOC. > > > > Here is my shell prompt > > > > [1] Shell > > [2] Boot Manager > > Start: 1 > First of all, please move to the Intel BDS. The ARM BDS (i.e., this menu system) is not UEFI compliant, and you will not be able to boot OS installers easily if you keep using it. Look at the repo history for ArmVExpress-FVP- AArch64.dsc for hints how to go about this.
I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which
one.
I will try again using the suggested DSC. thanks
> add-symbol-file >
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S
hellPk > g/Application/Shell/Shell/DEBUG/Shell.dll > 0x1A831000 > > Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 > Shell.efi > > UEFI Interactive Shell v2.1 > > EDK II > > UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000) > > Mapping table > > FS0: Alias(s):F3: > > VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB) > > No SimpleTextInputEx was found. CTRL-based features are not
usable.
> > No SimpleTextInputEx was found. CTRL-based features are not
usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Not a clue, sorry. But I suppose a missing protocol like that could explain the Intel BDS issue as well.
I think you are using EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf as your terminal driver. You can try using below drivers for a more powerful terminal:
INFMdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf INF
MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
INFMdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleD
xe.inf INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF EmbeddedPkg/SerialDxe/SerialDxe.inf
Heyi
You are right, I am using
"EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf"
I switched to Intel BDS and moved to the console implementations above
but the terminal simply freezes when the Bds should start.
Could it be since I am using a NULL extended serial port "
SerialPortExtLib|EmbeddedPkg/Library/SerialPortExtLibNull/SerialPortExtLib Null.inf" ?
I also tried using the Intel BDS with the SimpleTextInOutSerial but the console behaves strange. It prints too many spaces and line feeds I
can't get a proper view on the screen.
Is this a valid combination at all ?
> Press ESC in 5 seconds to skip startup.nsh or any other key to > continue > > > > From here on any key I press causes call to "GccSemihostCall" > which invokes a HW breakpoint on AArch64. > > I noticed GccSemihostCall doesn't trigger a breakpoint in ARM arch. > > I am using "
SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf"
> You don't need this library on bare metal if you are not using a debugger that supports semihosting. So the simple answer is to just remove it from your .DSC and .FDF files.
Okay. I just reused "...2nd-level.dsc" and still didn't filter the unnecessary stuff since frankly I don't yet understand what most packages do
> Do you have any idea why I get to "GccSemihostCall". ? > > Am I missing something in my system setup. ? > The shell tries to load 'startup.nsh' from the semihosting file system, using semihosting specific breakpoint instructions.
That make sense now. I should have mentioned I am connected with a
HW debugger so a HLT instruction just stops the execution.
> I copied the shell related packages from ArmVirtPkg since I know > it works there > Yes, that makes sense in itself, since it builds the shell from source rather than use the binary package.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
Hi Heyi
After some more debug I found out that during the Bds Phase prints that use DEBUG reach the screen but Prints that use "Print" which I believe use the console and not the serialLib do not reach the screen
I guess my console doesn't get initialized. Maybe I am missing some PCD ?
Thanks a lot
Yehuda
-----Original Message----- From: Yehuda Yitschak Sent: Monday, November 23, 2015 09:14 To: 'Heyi Guo'; Ard Biesheuvel Cc: Linaro-uefi@lists.linaro.org; Ryan Harkin Subject: RE: [Linaro-uefi] GccSemihostCall on Aarch64
-----Original Message----- From: Heyi Guo [mailto:heyi.guo@linaro.org] Sent: Monday, November 23, 2015 05:43 To: Yehuda Yitschak; Ard Biesheuvel Cc: Linaro-uefi@lists.linaro.org; Ryan Harkin Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
Hi Yehuda,
One possible reason that you cannot input in BDS is of UEFI timer issue; please check your uefi timer can interrupt normally.
I guess the timer is fine since I am able to fully operate the shell when I use ARM BDS and SimpleText The problem starts when I switch to the more powerful console. I don't even see the initial BDS prints The last visible print is :
add-symbol-file /home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/M deModulePkg/Universal/Disk/Uni codeCollation/EnglishDxe/EnglishDxe/DEBUG/EnglishDxe.dll 0x1F83E240 Loading driver at 0x0001F83E000 EntryPoint=0x0001F83E280 EnglishDxe.efi
All other console DXEs are loaded before so I guess the problem start when DXE switches to BDS.
And I think the SerialPortExtLib you're using is OK; I'm also using this library instance.
Regards,
Heyi
On 11/22/2015 10:22 PM, Yehuda Yitschak wrote:
Hi Heyi
-----Original Message----- From: Heyi Guo [mailto:heyi.guo@linaro.org] Sent: Friday, November 20, 2015 07:09 To: Ard Biesheuvel; Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 11/19/2015 11:51 PM, Ard Biesheuvel wrote:
On 19 November 2015 at 16:42, Yehuda Yitschak
wrote:
Hi Ard
Thanks for the prompt reply.
> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Thursday, November 19, 2015 17:31 > To: Yehuda Yitschak > Cc: Linaro-uefi@lists.linaro.org > Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64 > > On 19 November 2015 at 16:25, Yehuda Yitschak
> wrote: >> Hello everyone >> > Hello Yehuda, > >> I am trying to invoke the EDK2 shell on Aarch64 SOC. >> >> >> >> Here is my shell prompt >> >> >> >> [1] Shell >> >> [2] Boot Manager >> >> Start: 1 >> > First of all, please move to the Intel BDS. The ARM BDS (i.e., > this menu > system) is not UEFI compliant, and you will not be able to boot > OS installers easily if you keep using it. Look at the repo > history for > ArmVExpress-FVP- AArch64.dsc for hints how to go about this. I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which
one.
I will try again using the suggested DSC. thanks
>> add-symbol-file >>
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S
> hellPk >> g/Application/Shell/Shell/DEBUG/Shell.dll >> 0x1A831000 >> >> Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 >> Shell.efi >> >> UEFI Interactive Shell v2.1 >> >> EDK II >> >> UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000) >> >> Mapping table >> >> FS0: Alias(s):F3: >> >> VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB) >> >> No SimpleTextInputEx was found. CTRL-based features are not
usable.
>> >> No SimpleTextInputEx was found. CTRL-based features are not
usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Not a clue, sorry. But I suppose a missing protocol like that could explain the Intel BDS issue as well.
I think you are using EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf as your terminal driver. You can try using below drivers for a more powerful terminal:
INFMdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
INFMdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
INFMdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleD
xe.inf INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF EmbeddedPkg/SerialDxe/SerialDxe.inf
Heyi
You are right, I am using
"EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf"
I switched to Intel BDS and moved to the console implementations above
but the terminal simply freezes when the Bds should start.
Could it be since I am using a NULL extended serial port "
SerialPortExtLib|EmbeddedPkg/Library/SerialPortExtLibNull/SerialPortEx SerialPortExtLib|tLib Null.inf" ?
I also tried using the Intel BDS with the SimpleTextInOutSerial but the console behaves strange. It prints too many spaces and line feeds I
can't get a proper view on the screen.
Is this a valid combination at all ?
>> Press ESC in 5 seconds to skip startup.nsh or any other key to >> continue >> >> >> >> From here on any key I press causes call to "GccSemihostCall" >> which invokes a HW breakpoint on AArch64. >> >> I noticed GccSemihostCall doesn't trigger a breakpoint in ARM
arch.
>> >> I am using "
SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf"
>> > You don't need this library on bare metal if you are not using a > debugger that supports semihosting. So the simple answer is to > just remove it from your .DSC and .FDF files. Okay. I just reused "...2nd-level.dsc" and still didn't filter the unnecessary stuff since frankly I don't yet understand what most packages do
>> Do you have any idea why I get to "GccSemihostCall". ? >> >> Am I missing something in my system setup. ? >> > The shell tries to load 'startup.nsh' from the semihosting file > system, using semihosting specific breakpoint instructions. That make sense now. I should have mentioned I am connected with a
HW debugger so a HLT instruction just stops the execution.
>> I copied the shell related packages from ArmVirtPkg since I >> know it works there >> > Yes, that makes sense in itself, since it builds the shell from > source rather than use the binary package.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
Found it.
I was missing the ConIn ConOut device paths PCDs
Thanks everyone for your help
Yehuda
On Nov 25, 2015 6:32 PM, Yehuda Yitschak yehuday@marvell.com wrote: Hi Heyi
After some more debug I found out that during the Bds Phase prints that use DEBUG reach the screen but Prints that use "Print" which I believe use the console and not the serialLib do not reach the screen
I guess my console doesn’t get initialized. Maybe I am missing some PCD ?
Thanks a lot
Yehuda
-----Original Message----- From: Yehuda Yitschak Sent: Monday, November 23, 2015 09:14 To: 'Heyi Guo'; Ard Biesheuvel Cc: Linaro-uefi@lists.linaro.org; Ryan Harkin Subject: RE: [Linaro-uefi] GccSemihostCall on Aarch64
-----Original Message----- From: Heyi Guo [mailto:heyi.guo@linaro.org] Sent: Monday, November 23, 2015 05:43 To: Yehuda Yitschak; Ard Biesheuvel Cc: Linaro-uefi@lists.linaro.org; Ryan Harkin Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
Hi Yehuda,
One possible reason that you cannot input in BDS is of UEFI timer issue; please check your uefi timer can interrupt normally.
I guess the timer is fine since I am able to fully operate the shell when I use ARM BDS and SimpleText The problem starts when I switch to the more powerful console. I don’t even see the initial BDS prints The last visible print is :
add-symbol-file/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/M deModulePkg/Universal/Disk/Uni codeCollation/EnglishDxe/EnglishDxe/DEBUG/EnglishDxe.dll 0x1F83E240 Loading driver at 0x0001F83E000 EntryPoint=0x0001F83E280 EnglishDxe.efi
All other console DXEs are loaded before so I guess the problem start when DXE switches to BDS.
And I think the SerialPortExtLib you're using is OK; I'm also using this library instance.
Regards,
Heyi
On 11/22/2015 10:22 PM, Yehuda Yitschak wrote:
Hi Heyi
-----Original Message----- From: Heyi Guo [mailto:heyi.guo@linaro.org] Sent: Friday, November 20, 2015 07:09 To: Ard Biesheuvel; Yehuda Yitschak Cc: Linaro-uefi@lists.linaro.org Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64
On 11/19/2015 11:51 PM, Ard Biesheuvel wrote:
On 19 November 2015 at 16:42, Yehuda Yitschak
wrote:
Hi Ard
Thanks for the prompt reply.
> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Thursday, November 19, 2015 17:31 > To: Yehuda Yitschak > Cc: Linaro-uefi@lists.linaro.org > Subject: Re: [Linaro-uefi] GccSemihostCall on Aarch64 > > On 19 November 2015 at 16:25, Yehuda Yitschak
> wrote: >> Hello everyone >> > Hello Yehuda, > >> I am trying to invoke the EDK2 shell on Aarch64 SOC. >> >> >> >> Here is my shell prompt >> >> >> >> [1] Shell >> >> [2] Boot Manager >> >> Start: 1 >> > First of all, please move to the Intel BDS. The ARM BDS (i.e., > this menu > system) is not UEFI compliant, and you will not be able to boot > OS installers easily if you keep using it. Look at the repo > history for > ArmVExpress-FVP- AArch64.dsc for hints how to go about this. I tried but I hit a wall during DXE phase. The BDS DXE failed to load complaining on a missing architectural protocol I never got to figure which
one.
I will try again using the suggested DSC. thanks
>> add-symbol-file >>
/home/yehuday/projects/uefi/edk2/Build/SOC/DEBUG_GCC48/AARCH64/S
> hellPk >> g/Application/Shell/Shell/DEBUG/Shell.dll >> 0x1A831000 >> >> Loading driver at 0x0001A830000 EntryPoint=0x0001A831000 >> Shell.efi >> >> UEFI Interactive Shell v2.1 >> >> EDK II >> >> UEFI v2.50 (Marvell EFI Nov 19 2015 09:40:40, 0x00000000) >> >> Mapping table >> >> FS0: Alias(s):F3: >> >> VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB) >> >> No SimpleTextInputEx was found. CTRL-based features are not
usable.
>> >> No SimpleTextInputEx was found. CTRL-based features are not
usable.
Is this warning an issue.? Do you know how to resolve it if necessary ?
Not a clue, sorry. But I suppose a missing protocol like that could explain the Intel BDS issue as well.
I think you are using EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf as your terminal driver. You can try using below drivers for a more powerful terminal:
INFMdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
INFMdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
INFMdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleD
xe.inf INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF EmbeddedPkg/SerialDxe/SerialDxe.inf
Heyi
You are right, I am using
"EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf"
I switched to Intel BDS and moved to the console implementations above
but the terminal simply freezes when the Bds should start.
Could it be since I am using a NULL extended serial port "
SerialPortExtLib|EmbeddedPkg/Library/SerialPortExtLibNull/SerialPortEx SerialPortExtLib|tLib Null.inf" ?
I also tried using the Intel BDS with the SimpleTextInOutSerial but the console behaves strange. It prints too many spaces and line feeds I
can't get a proper view on the screen.
Is this a valid combination at all ?
>> Press ESC in 5 seconds to skip startup.nsh or any other key to >> continue >> >> >> >> From here on any key I press causes call to “GccSemihostCall” >> which invokes a HW breakpoint on AArch64. >> >> I noticed GccSemihostCall doesn’t trigger a breakpoint in ARM
arch.
>> >> I am using “
SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf”
>> > You don't need this library on bare metal if you are not using a > debugger that supports semihosting. So the simple answer is to > just remove it from your .DSC and .FDF files. Okay. I just reused "...2nd-level.dsc" and still didn’t filter the unnecessary stuff since frankly I don’t yet understand what most packages do
>> Do you have any idea why I get to “GccSemihostCall”. ? >> >> Am I missing something in my system setup. ? >> > The shell tries to load 'startup.nsh' from the semihosting file > system, using semihosting specific breakpoint instructions. That make sense now. I should have mentioned I am connected with a
HW debugger so a HLT instruction just stops the execution.
>> I copied the shell related packages from ArmVirtPkg since I >> know it works there >> > Yes, that makes sense in itself, since it builds the shell from > source rather than use the binary package.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
-
Ard Biesheuvel -
Heyi Guo -
Ryan Harkin -
Yehuda Yitschak