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