Laszlo,
The leading "_" was required for out of spec, but built in, commands. The spec
has no restrictions on environment variables except some have special meaning
and may be read only.
I can certainly work on slowing down the process. I have been complaining
about that same thing and
On 10/04/18 21:05, jim.dai...@dell.com wrote:
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>
> I'll attempt answer some of your questions, but Jaben may have to
> answer some of them (like his commit speed :-) or questions about what
> the shell spec
> On Oct 4, 2018, at 10:07 AM, Laszlo Ersek wrote:
>
> On 10/03/18 20:17, Carsey, Jaben wrote:
>> Pushed.
>> c0b1f749ef1304810ed4ea58ded65b7f41d79d3e
>
> Please give other reviewers a bit more time than ~2 hours, to comment on
> the patch. :)
>
> I think I would have suggested an
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
>Ersek
I'll attempt answer some of your questions, but Jaben may have to
answer some of them (like his commit speed :-) or questions about what
the shell spec allows).
>
>So my first question would have been, what if
On 10/03/18 20:17, Carsey, Jaben wrote:
> Pushed.
> c0b1f749ef1304810ed4ea58ded65b7f41d79d3e
Please give other reviewers a bit more time than ~2 hours, to comment on
the patch. :)
I think I would have suggested an improvement (or a clarification about)
the commit message. It says:
>>
On 10/04/18 12:56, Hristo Mihaylov wrote:
> Hello,
>
> I have an issue that I don't know how to fix. I'm building a BIOS for a custom
> x86_64 platform.
>
> The first part of the problem is: the BIOS boots to the end of DXE where
> it crashes with a General Protection exception.
>
> ```
>
Ah, here's UsbSerialNumberLib. Got it.
(Please mention dependencies on other patchsets in the cover-letter.)
Please wrap these 3 sets together into a single one, with patches in
dependency order, for v2.
I will comment on this patch aftes I'm done with DwUsb2.
/
Leif
On Mon, Aug 20, 2018
ShellPkg-Cd: Ensure all valid cd targets are handled properly
Make sure that PathCleanUpDirectories() is called on all valid targets
of the cd command.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey
---
ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c | 8
On Mon, Aug 20, 2018 at 06:31:25PM +0800, Haojian Zhuang wrote:
> Add Designware USB 3.0 device driver. It's focus on USB device
> functionality, not USB Host functionality. The USB driver is
> mainly used for Android Fastboot application.
>
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
>
MdePkg-BaseLib: Fix PathCleanUpDirectories() error involving "\..\.."
The loop that removes "\..\" errs when multiple "\.." sequences are
in the path. Before this change the code would modify a path like
"FS0:\efi\tools\..\.." to "FS0:\efi\\.." and then to "FS0:\efi\", but
the correct path
On Mon, Aug 20, 2018 at 06:31:24PM +0800, Haojian Zhuang wrote:
> The protocol defines the callbacks that could be implemented in
> platform driver. DwUsb device driver needs these callbacks to
> implement USB device functionality.
>
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> Contributed-under:
Hi Haojian,
I will start with a few high-level requests:
- Could you rework this for inclusion in edk2-platforms instead?
Silicon/Synopsys I guess?
- Could you submit Usb2 and Usb3 support in a single set for v2?
- Can you convert these to UEFI driver model with
On 10/04/18 11:24, Leif Lindholm wrote:
> +Peter
>
> On Wed, Oct 03, 2018 at 04:59:54PM -0700, aaron.yo...@oracle.com wrote:
>> I am suspecting that this patch to GRUB is the cause of a Buffer being
>> re-transmitted before reaping the Buffer via SNP->GetStatus():
>>
>>
Hello,
I have an issue that I don't know how to fix. I'm building a BIOS for a custom
x86_64 platform.
The first part of the problem is: the BIOS boots to the end of DXE where
it crashes with a General Protection exception.
```
X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID
+Peter
On Wed, Oct 03, 2018 at 04:59:54PM -0700, aaron.yo...@oracle.com wrote:
> I am suspecting that this patch to GRUB is the cause of a Buffer being
> re-transmitted before reaping the Buffer via SNP->GetStatus():
>
>
15 matches
Mail list logo
