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
> > <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/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