Hi,
For next (probably red-tape based) decisions on spec update (on the fly
here)...
To make the UEFI based systems consistent and flexible to run UEFI based
applications of all kinds:
1 - Require ATA Pass-Thru Protocol on all ATA devices. Protocol would be
optional for ATAPI.
2 - Require SCSI
On Thu, Sep 05, 2013 at 02:36:15PM +0200, Laszlo Ersek wrote:
> On 09/05/13 10:46, Michael Chang wrote:
> > On Thu, Sep 05, 2013 at 03:20:05AM +0200, Laszlo Ersek wrote:
> >> On 08/28/13 20:12, Laszlo Ersek wrote:
> >>> The prefix matching logic in Match()
> >>> [OvmfPkg/Library/PlatformBdsLib/Qemu
Yes, but to do it right you really need the SCSI Pass Through Interface to
talk directly with the device as you may need to send setup or blank
commands, etc... Also for ATA devices, be nice for the various commands
dealing with their command set.
On Thu, Sep 5, 2013 at 7:42 PM, Sergey Isakov
Andrew,
I've already moved the patch out of ShellPkg in my environment and in to
MdePkg so the attached suggested patch reflects that. Also, I had to do a
diff on two files to create the patch, I used the GIT tool because it
created a good patch, the SVN diff just - all of them and + all of them.
Hi David,
I am not understanding what are you going to do. How did you propose to burn
DVD in UEFI mode? Do you have such UEFI application to burn DVD?
Sergey.
On 06.09.2013, at 6:22, David F. wrote:
> Well, without any passthru support, I'm not sure how I'm, as an application,
> supposed to g
Well, without any passthru support, I'm not sure how I'm, as an
application, supposed to get the device names of the various hard drives
and dvd drives in the system? Also, how you would be able to burn a CD/DVD
and send the various commands to setup for the burn. I see the Visual
BIOS on the sys
Can you get a stack trace of the hang?
It could be you are passing in an invalid handle, but the DXE Core should check
for this via the EFI_HANDLE_SIGNATURE that it uses internally to make sure
handles are valid.
Thanks,
Andrew Fish
On Sep 5, 2013, at 12:44 PM, "David F." wrote:
> Hi,
>
>
If you get this build error "unresolved external _memset in aLibrary.lib
(aSource.obj)"
It takes a bit of time to solve because the build log doesn't provide a
detailed clue. One way the issue can show up is when you are looping over an
array and setting the array item to 0. The compiler deci
I find it hard to believe but it looks like there is no PassThru anything
on this system as LocateHandleBuffer returns nothing for ATA, SCSI or
ExtSCSI. Be nice if it was required by UEFI systems to provide that.
On Thu, Sep 5, 2013 at 5:05 PM, David F. wrote:
> Hi,
>
> So I open a Block IO Pr
On Sep 5, 2013, at 12:41 PM, Fernando Ferraz wrote:
> Hi,
>
> I've created a function that fills a linked list containing blocks of 1024kB
> and a pointer to the next node.
>
> my struct is something like this:
>
> typedef struct _Buffer {
> UINT64 Len; //By default 1024*1024
> UINT64 *
Hi,
I've created a function that fills a linked list containing blocks of
1024kB and a pointer to the next node.
my struct is something like this:
typedef struct _Buffer {
UINT64 Len; //By default 1024*1024
UINT64 *InitialAddress; //Pointer to the the 1024K buffer
struct _Buffer *Next; //P
Hello All,
Please go through the trail information and let me know your suggestions.
*My setup Details:*
My motherboard (Host-x86) is connected with arm based PCI board over
PCIe.There are four SATA and SCSI devices are connected on arm board.
*My requirement :*
We have written a PCI linux dev
You could probably also write an assembly stub that does a tail call do the
same thing and avoid the compiler specific #pragmas.
My MASM is very rusty, but something like:
.code
EXTERNDEF SetMem32:PROC
;--
; VOI
Hi,
So I open a Block IO Protocol, also get the Device Path. Then do:
EFI_STATUS OpenParentProtocol(EFI_DEVICE_PATH_PROTOCOL *devpath, EFI_GUID
*protocolguid, void **protocolinterface)
EFI_HANDLE devhandle;
EFI_STATUS status=UEFI_BS->LocateDevicePath(protocolguid, &devpath,
&devhandle);
<.
On Sep 5, 2013, at 11:47 AM, "Hamel, Lee M" wrote:
> If you get this build error "unresolved external _memset in aLibrary.lib
> (aSource.obj)"
>
> It takes a bit of time to solve because the build log doesn’t provide a
> detailed clue. One way the issue can show up is when you are looping o
Sorin,
Depending on the APIs that are called between each call to AllocatePages(),
memory may be allocated or freed which may cause the memory map to change.
You need to make sure there are no API calls that either directly or indirectly
allocate memory between the call to GetMemoryMap() and th
I think the error Lee is talking about is due to MSVC Whole Program
Optimization. We were able to work around this by using #pragmas to tell MSVC
to use our own functions for memcpy and memset instead of the compiler's
intrinsic implementations. These functions simply wrap around CopyMem() and
You can download the UEFI 2.4 specification from http://www.uefi.org/specs/
and section 2.6 talks about requirements for drivers, and chapter 13 talks
about the PCI Driver Model.
There is a UEFI driver writers guide at
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UEFI_Drive
Hi,
Using the SafeOpenProtocolLib in an application which basically does a
BY_DRIVER open if it can, if not then a BY_DRIVER | EXCLUSIVE to force
things off if it can, if that works then when it closes the protocol it
also calls reconnect(). A few things based on that...
1 - Media Paths Can't be
I don't have a debugger setup on the system, nor do I know how to, just
using the old printf method. I did check that the handle opened eariler
is the same one being reopened down below. I did notice also that on each
z-loop the handles that opened remained the same on each loop where as the
med
On Sep 5, 2013, at 9:39 AM, "Kinney, Michael D"
wrote:
> Sorin,
>
> Depending on the APIs that are called between each call to AllocatePages(),
> memory may be allocated or freed which may cause the memory map to change.
>
> You need to make sure there are no API calls that either directly
On 09/05/13 10:46, Michael Chang wrote:
> On Thu, Sep 05, 2013 at 03:20:05AM +0200, Laszlo Ersek wrote:
>> On 08/28/13 20:12, Laszlo Ersek wrote:
>>> The prefix matching logic in Match()
>>> [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options
>>> to specify full (absolute) de
On 09/05/13 12:18, Michael Chang wrote:
> Hm..while I was testing another patch, occasionally I found that efi
> boot entries were duplicating on every reboot. After several cycles I
> have the following boot entries ..
>
> BootCurrent: 0005
> BootOrder: 0005
> Boot* EFI DVD/CDROM ACPI(a0341d
On Mon, Aug 26, 2013 at 12:46:32PM +0800, Michael Chang wrote:
> On Fri, Aug 23, 2013 at 08:33:31PM +0200, Laszlo Ersek wrote:
> > On 08/23/13 11:27, Michael Chang wrote:
> > > On Thu, Aug 22, 2013 at 06:05:58PM -0700, Jordan Justen wrote:
> > >> On Mon, Aug 19, 2013 at 3:00 AM, Michael Chang wrot
On Thu, Sep 05, 2013 at 03:20:05AM +0200, Laszlo Ersek wrote:
> On 08/28/13 20:12, Laszlo Ersek wrote:
> > The prefix matching logic in Match()
> > [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options
> > to specify full (absolute) device paths. However, partial (relative)
> >
Liming,
I am allocating memory iterative in each of the free memory blocks retrieved
from the memory map, including 8000, 59000, 10, 110, 1461,
2020, and allocation succeeds. The only problem is at 131D address.
From what I observed, every new memory request is allocated sta
EDKII provides UefiBootServicesTableLib and UefiRuntimeServicesTableLib to
access gBS and gRT.
You need to include Library header file in source file, and list LibraryName in
module INF file, then configure LibraryInstance in your DSC file.
Thanks
Liming
From: parmeshwr_pra...@dell.com [mailto:p
Hi All,
I have just started programming in UEFI.
Can any one guide me how to access gBS, what configuration I need to make in
package. dsc or package.inf file ?
Best Regards,
Parmeshwr Prasad
Tel : +91-9743262018
[cid:image001.png@01CEAA36.EAA12BB0]
<>-
28 matches
Mail list logo
