Laszlo,
I will refine the change in OvmePkg when I check in the code, also attach the
uni file this patch.
Thanks,
Eric
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, July 23, 2013 11:14 PM
To: Dong, Eric
Cc: edk2-devel@lists.sourceforge.net
Subject: Re:
Martin:
I have some comments.
1. Some header file describes its Reference spec version, such as
MdePkg\Include\Protocol\PxeBaseCode.h. I suggest you update its version to
UEFI2.4.
2. For StatusCode definition update, I don't find such change in public PI1.3
spec. Have they been integrated int
Hi Vincent
May you kindly give more detailed implementation guidance? Meanwhile
I will try to contact Intel filed representative.
Thanks
Best wishes,
Stanley
-邮件原件-
发件人: Zimmer, Vincent [mailto:vincent.zim...@intel.com]
发送时间: 2013年7月24日 8:18
收件人: stanley.ganyezu; 'Andrew Fish'
抄
Hi Eric,
On 07/24/13 10:04, Dong, Eric wrote:
>
> I will refine the change in OvmePkg when I check in the code, also attach the
> uni file this patch.
Thank you.
I needed the attached patches to build OvmfPkg on RHEL-6.4 (gcc-4.4).
(Some of them are probably incorrect.)
Unfortunately, even wi
On 07/24/13 01:36, Andrew Fish wrote:
> EFI requests mappings for physical address ranges in the memory map by
> setting the attribute bit EFI_MEMORY_RUNTIME. The OS (or loader
> depending on the OS design), after ExitBootServices() calls
> SetVirtualAddressMap() to provide the firmware with the vi
I have just realized I missed the file 'MdePkg/Include/AArch64/ProcessorBind.h'
in the previous patch 'MdePkg-Added-ARM-Aarch64-architecture-support.patch'.
The attached patch should fix this issue.
> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: 24 Ju
Laszlo,
The translation from physical to virtual is described in an EFI Memory Map.
Each memory map entry in the EFI Memory Map provides a base address and a
length. SetVirtualAddressMap() can not break up the memory map entries into
smaller entries. This means if an array larger than one 4K
On Jul 24, 2013, at 4:27 AM, Laszlo Ersek wrote:
> On 07/24/13 01:36, Andrew Fish wrote:
>> EFI requests mappings for physical address ranges in the memory map by
>> setting the attribute bit EFI_MEMORY_RUNTIME. The OS (or loader
>> depending on the OS design), after ExitBootServices() calls
>>
On 07/24/13 18:15, Kinney, Michael D wrote:
> [...] SetVirtualAddressMap() can not break up
> the memory map entries into smaller entries. [...]
Thank you both for the answers!
Laszlo
--
See everything from the browser t
I've not seen any thoughts on this so here goes. Some one who understands
source control better than me might have a better idea.
I think something like this could work with git.
Add a Platform directory to /trunk/edk2. Move EmulatorPkg, Nt32Pkg, OvmfPkg (we
could make this a separate project
Hi Laszlo,
In SetVirtualAddressMap, is CPU running at virtual mode or physical mode?
How do OS construct VirtualMap? Based on EFI memory map? Or OS add some
changes?
Thanks
Best wishes,
Stanley
-邮件原件-
发件人: Laszlo Ersek [mailto:ler...@redhat.com]
发送时间: 2013年7月25日 0:25
收件人: Kinney,
I'd recommend reading UEFI 2.4 sections about the boot and runtime services
mentioned in this post...
On Jul 24, 2013, at 9:49 AM, "stanley.ganyezu"
wrote:
> Hi Laszlo,
> In SetVirtualAddressMap, is CPU running at virtual mode or physical mode?
Physical mode. The OS can only call runtime ser
On 07/24/13 18:49, stanley.ganyezu wrote:
> Hi Laszlo,
> In SetVirtualAddressMap, is CPU running at virtual mode or physical mode?
> How do OS construct VirtualMap? Based on EFI memory map? Or OS add some
> changes?
Unfortunately, I can only direct you to
- "7.4 Virtual Memory Services" in th
Hi all,
I am sorry to ask such a simple question and I swear before asking to this
list I've searched for some solutions and couldn't fine one that worked for
me.
I need to make some basic file operations using the fopen and fclose. So,
my code is this simple:
--
#include
#include
int main(in
Mauro,
After a quick scan of your email, I can’t see anything wrong.
I’ll try to reproduce it this afternoon and get back to you with my results.
Sorry, but I have to ask the following stupid questions.
1) What happens if you enter “type fs0:\file.txt” at a (U)Efi Shell prompt?
2) Hav
Hi Daryl,
Thank you for your quick answer.
that command shows the file content as expected.
I'll try to check the information you suggested and post the results here.
Mauro
On Wed, Jul 24, 2013 at 2:52 PM, Mcdaniel, Daryl
wrote:
> Mauro,
>
> ** **
>
> After a quick scan of your email
Here are the information.
The (meaningful) code:
--
char currentdir[1024];
if(getcwd(currentdir, sizeof(currentdir))!= NULL){
printf("Working dir: '%s'\n", currentdir);
}
if(fopen("test.txt", "rb") == NULL)
{
printf("fopen failed. errno = %d\n", errno);
perror("Cou
Dear XhciDxe Maintainer,
I'm currently reviewing the XhciDxe driver and I'm trying to figure out how DMA
buffers are allocated. I see a number of pool and page allocations but I do
not see any called to PCI_IO Map()/Unmap() or to AllocateBuffer()/FreeBuffer().
This appears to be violating the
In NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c, the code attempts to free
Private->BootFileName, but that was not directly allocated using UEFI memory
services (it points directly to a portion of a parsed packet data, so the
overall buffer for the packet was allocated, but not "BootFileName" directly.).
Here is an observation with PrintLib :
UINT16 myuint16 = 0x;
Print(L"%d", myuint16) -->displays 65535.
So far, so good.
UINT32 myuint32 = 0x;
Print(L"%d", myuint32) --> displays-1
Print(L"%ld", myuint32)-->
Samer,
I think we may need some clarifications in the PrintLib.h. The data type in
the format string descriptions are there to make sure the size of each variable
argument is defined so the variable argument list is parsed correctly.
%x, %lx, %X, and %lX are consistent printed as unsigned valu
Hi Andrew,
Thanks for good answers.
Best wishes,
Stanley
-邮件原件-
发件人: Andrew Fish [mailto:af...@apple.com]
发送时间: 2013年7月25日 1:15
收件人: stanley.ganyezu
抄送: 'Laszlo Ersek'; edk2-devel@lists.sourceforge.net
主题: Re: [edk2] 答复: runtime service address translation
I'd recommend readi
I think it would be good to find some way to organize this better.
Currently the DuetPkg and Nt32Pkg are part of the UDK releases. I think it
would be better to have a grouping of packages related to emulator support
that included these as well as EmulatorPkg, UnixPkg and OvmfPkg, and then
remove t
On Jul 24, 2013, at 4:51 PM, Chip Ueltschey wrote:
> I think it would be good to find some way to organize this better.
> Currently the DuetPkg and Nt32Pkg are part of the UDK releases. I think it
> would be better to have a grouping of packages related to emulator support
> that included thes
Mike,
Thanks for the clarification. This means Print() cannot print a 64-bit unsigned
value in a decimal formatted output, but can handle it in a hex formatted
output. I think this is fine. Updating the library comments is sufficient.
Thanks,
--Samer
From: Kinney, Michael D [mailto:michael.d.
Hi, Eugene
The EDKII XhciDxe driver doesn't use PciIo.AllocateBuffer()/Map() to allocate
DMA buffers. It's mainly because EDKII is 1:1 mapping on Pci physical address
and Cpu logical address for IA architecture. AllocateBuffer() is enough for
current case.
We only implement this feature at EHC
On Jul 24, 2013, at 5:27 PM, "Tian, Feng" wrote:
> Hi, Eugene
>
> The EDKII XhciDxe driver doesn’t use PciIo.AllocateBuffer()/Map() to allocate
> DMA buffers. It’s mainly because EDKII is 1:1 mapping on Pci physical address
> and Cpu logical address for IA architecture. AllocateBuffer() is e
Sorry, Andrew.
I don't understand your point, where of XhciDxe current implementation is
disobeying UEFI spec? Do I miss something?
2.6.3 Driver-Specific Elements:
12. If a driver is written for a PCI root bridge, then the
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and the EFI_PCI_IO_PROTOCOL must be impl
On Jul 24, 2013, at 5:59 PM, "Tian, Feng" wrote:
> Sorry, Andrew.
>
> I don’t understand your point, where of XhciDxe current implementation is
> disobeying UEFI spec? Do I miss something?
>
> 2.6.3 Driver-Specific Elements:
> 12. If a driver is written for a PCI root bridge, then the
> EF
Agree. Adding such sentence to UEFI spec would be more clear.
Then I need to check all PCI host controller drivers to see if we meet such new
requirement:)
From: Andrew Fish [mailto:af...@apple.com]
Sent: Thursday, July 25, 2013 9:04 AM
To: Tian, Feng
Cc: Cohen, Eugene; edk2-devel@lists.sourcefo
30 matches
Mail list logo
