On 08/28/14 17:26, Ard Biesheuvel wrote:
> On 28 August 2014 16:30, Laszlo Ersek <[email protected]> wrote:
>> comments below
>>
>> On 08/27/14 17:12, Ard Biesheuvel wrote:
>>> + # Use the serial console (ConIn & ConOut) and the Graphic driver
>>> (ConOut)
>>> +
>>> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()"
>>> +
>>> gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()"
>>> + gArmPlatformTokenSpaceGuid.PcdPlatformBootTimeOut|3
>>
>> Okay, looks like we managed to request VT100 terminals after all! :)
>>
>
> Well, at least I tried :-)
> It doesn't really seem to make a difference, re ^H for backspace etc
Something for later then. I think this is debuggable.
Just a quick idea: have you tried reinitializing your variable store?
See InitializeConsole() in "ArmPlatformPkg/Bds/Bds.c".
I'd sprinkle the following functions with DEBUG()s:
InitializeConsole() [ArmPlatformPkg/Bds/Bds.c]
GetConsoleDevicePathFromVariable()
InitializeConsolePipe()
In particular, the following call chain:
InitializeConsole() [ArmPlatformPkg/Bds/Bds.c]
InitializeConsolePipe()
BdsConnectDevicePath() [ArmPkg/Library/BdsLib/BdsFilePath.c]
BdsConnectAndUpdateDevicePath()
gBS->ConnectController()
should terminate, indirectly, in
TerminalDriverBindingStart()
[MdeModulePkg/Universal/Console/TerminalDxe/Terminal.c]
BuildTerminalDevpath()
where BuildTerminalDevpath() should see the VT100 type (gEfiVT100Guid).
Anyway, this is certainly for later.
>>> +
>>> + #
>>> + # UEFI application (Shell Embedded Boot Loader)
>>> + #
>>> + INF ShellBinPkg/UefiShell/UefiShell.inf
>>
>> It would be nice *not* to use the prebuilt UEFI shell binary. Instead,
>> we could build the UEFI shell from source. Please search OvmfPkgX64.dsc
>> and OvmfPkgX64.fdf for "ShellPkg/Application/Shell/Shell.inf", and
>> consider stealing what you can.
>>
>> This allows you to do UEFI shell development flexibly -- your develop /
>> build / reboot / test cycle can now cover the UEFI shell as well. It
>> also enables you to take advantage of ShellPkg commits as soon as they
>> appear in the tree, no need to wait for periodic binary syncs in
>> ShellBinPkg.
>>
>
> Well, to be honest, I'd prefer to do what all the other ARM kids our
> doing, as that means less potential surprises for people switching
> between real systems and this QEMU build.
That's a valid point.
>> Also, I'd prefer if each PCD was mentioned only once, across the DSC and
>> the DSC.inc cumulatively, but this is really the lowest priority
>> imaginable.
>>
>
> Well, the idea is more or less to put reasonable default for all virt
> targets (QEMU, Xen) there, and specialize in the .dsc
> But I know too little about Xen to be able to even predict where the
> split would end up, so I kind of left it as I found it.
I understand; thanks for the explanation.
Laszlo
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
