Anyone given thought to adding a flag to PrintLib for printing device
paths? Seems to be a very common thing to do and using the device path to
text protocol gets tedious. If this is not a good idea, can someone educate
me? Thanks.
Thomas Rognon
On Sat, 2013-11-16 at 20:07 +0100, Laszlo Ersek wrote:
> On 09/28/13 20:51, Mark Salter wrote:
> > On Fri, 2013-09-27 at 02:31 +0200, Laszlo Ersek wrote:
> >> Hi Mark,
> >>
> >> just my 2 cents:
> >>
> >> On 09/26/13 21:33, Mark Salter wrote:
> >>> I've been trying out this patch series on AArch64
Hi Feng,
Thanks for your support.
For example, which device type does your SAS driver return? EDKII
ScsiDisk only manages EFI_SCSI_TYPE_DISK and EFI_SCSI_TYPE_CDROM.
My SAS driver returns device type as DISK. I could install
EXT_SCSI_PASS_THRU and EFI_DEVICE_PATH_PROTOCOL in my sas driver.
It means you didn't implement EXT_SCSI_PASS_THRU. GetNextTargetLun() correctly.
Please read UEFI Spec EXT_SCSI_PASS_THRU section at first.
OptionRomPkg\AtapiPassThruDxe is also a sample for you.
-Original Message-
From: Murali Selvaraj [mailto:murali.selva...@lntinfotech.com]
Sent: Mond
Hi, David
The similar thing we met is some DVD+R/DVD-R discs would read fail with
DVD-Only drive if we try to read a lot of sectors(65535) one time. But using
DVD Combo drive would be successful. Legacy and UEFI boot all have such issues,
which is different with your description.
After experim
Hello,
I compiled OVMF from the lastest revision available on git sourceforge.
I run it with the command:
qemu-system-x86_64 -device rtl8139,netdev=tap0 -netdev
tap,id=tap0,ifname=tap0,script=no -bios
Build/OvmfX64/DEBUG_GCC47/QEMU/bios.bin -boot order=n
This combination of -device and -netdev w
