Wei,
I recommend you put the declaration of the new PCD in the next section if
MdeModulePkg.dec so it supports PatchableInModule as well.
Thanks,
Mike
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Tuesday, November 26, 2013 11:26 AM
To: edk2-devel@lists.sourcefor
E820 definitions copied from IntelFrameworkModulePkg/Csm/
LegacyBiosDxe/LegacyBiosInterface.h.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu
Reviewed-by: Jordan Justen
---
OvmfPkg/Include/IndustryStandard/E820.h | 46 +++
1 file cha
This is useful for initializing memory map.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu
---
OvmfPkg/PlatformPei/Platform.c |8 +++-
OvmfPkg/PlatformPei/Platform.h |5 +
OvmfPkg/PlatformPei/Xen.c | 12 +---
3 files changed, 13 inse
Hi all
This is version 3 of this series. RFC tag is dropped.
The first patch adds PcdPciDisableBusEnumeration in MdeModulePkg, which
short-circuits full enumeration if set to true.
We maintain some Xen specific functions at the moment, hopefully when QEMU /
KVM figures out what to do with memory
Platforms such as Xen already enumerates PCI bridges and devices. Use
this PCD to control EDK2 behavior.
PcdPciDisableBusEnumeration is placed under [PcdFixedAtBuild,
PcdDynamic, PcdDynamicEx], so that it is possible to alter it during
runtime.
The default setting of this PCD is false (allow full
This patch sets PcdPciDisableBusEnumeration to true then makes use of
PublishPeiMemory and XenMemMapInitialization to construct memory map for
Xen guest.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu
---
OvmfPkg/OvmfPkgIa32.dsc |5 +++--
OvmfPkg/O
EFI_XEN_OVMF_INFO is defined to accept configurations from hvmloader. It
must match the definition on Xen side.
XenInfo is extended to include necessary bits as well. Currently only E820
map is in use.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu
---
OvmfPkg/In
This function parses Xen OVMF info and arrange memory maps accordingly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu
---
OvmfPkg/PlatformPei/Platform.c | 70
1 file changed, 70 insertions(+)
diff --git a/OvmfPkg/Platfo
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu
---
OvmfPkg/PlatformPei/Xen.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
index a720b91..737cb15 100644
--- a/Ovmf
MemDetect actully does too many things, the underlying platform might
want to have more control over memory layout.
Extract the functionality of publishing PEI memory to a dedicated
function.
Also fixed wrong comment while I was there.
Contributed-under: TianoCore Contribution Agreement 1.0
Sign
On Tue, Nov 26, 2013 at 5:32 AM, Laszlo Ersek wrote:
> On 11/26/13 13:36, Markus Armbruster wrote:
>
>> Your stated purpose for multiple -pflash:
>>
>> This accommodates the following use case: suppose that OVMF is split in
>> two parts, a writeable host file for non-volatile variable stor
Hi All,
Currently, I am developing a EFI driver which will communicate with my IDE
controller and dump ModelName,sectors_per_track,heads and Firmware version.
My EFI driver able to communicate and it is identified two IDE channel also
detect the connected device as Hard disk. I have no issues it
On Tue, Nov 26, 2013 at 2:16 AM, Ian Campbell wrote:
> On Mon, 2013-11-25 at 12:00 -0800, Jordan Justen wrote:
>> What about when the next blob type needs to be transferred?
>
> When I put the SeaBIOS version together my intention was that the length
> field would serve as a proxy for the struct v
Thank you Olivier.
On Tue, Nov 26, 2013 at 12:55 PM, Olivier Martin wrote:
> FYI, the UEFI spec 2.4 has introduced the "New Random Number Generator"
> Protocol.
>
>> -Original Message-
>> From: Mauro Faccenda [mailto:facce...@gmail.com]
>> Sent: 20 November 2013 16:54
>> To: edk2-devel@li
FYI, the UEFI spec 2.4 has introduced the "New Random Number Generator"
Protocol.
> -Original Message-
> From: Mauro Faccenda [mailto:facce...@gmail.com]
> Sent: 20 November 2013 16:54
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] best way to generate an arbitrary long random da
On 26 November 2013 14:34, Olivier Martin wrote:
> Using any other BDS implementations will have the same limitation.
>
>
>
> My recommendation for your Continuous Integration Infrastructure to test
> UEFI on the ARM models:
>
> 1) Generate a reference flash image that contains your boot en
Using any other BDS implementations will have the same limitation.
My recommendation for your Continuous Integration Infrastructure to test UEFI
on the ARM models:
1) Generate a reference flash image that contains your boot entries (using
the parameters motherboard.flashloader1.fnameWrite=
Il 26/11/2013 14:53, Laszlo Ersek ha scritto:
>> >
>> > IIUC in the case of OVMF the guest "just knows" that there are multiple
>> > devices backing the range. Is that right?
> No, the guest (the flash driver) is unaware of that. It could know if it
> wanted to, but it doesn't care. It cares abou
On 11/26/13 14:46, Wei Liu wrote:
> On Mon, Nov 25, 2013 at 12:38:04PM -0800, Jordan Justen wrote:
>> Regarding patches 5-7, it seems like the mem-map code flow could be
>> more shared. It is a bit challenging to unravel things though.
>>
>
> Indeed. It's a bit unfortunate that this path is shared
On 11/26/13 14:41, Paolo Bonzini wrote:
> Il 25/11/2013 20:45, Laszlo Ersek ha scritto:
>> From looking at "hw/block/pflash_cfi01.c", it seems that the guest can
>> interrogate the flash device about its size (nb_blocs is stored in
>> cfi_table starting at 0x2D, and cfi_table can be queried by comm
On Mon, Nov 25, 2013 at 12:38:04PM -0800, Jordan Justen wrote:
> Regarding patches 5-7, it seems like the mem-map code flow could be
> more shared. It is a bit challenging to unravel things though.
>
Indeed. It's a bit unfortunate that this path is shared by all users of
OVMF. And from a previous
Il 25/11/2013 20:45, Laszlo Ersek ha scritto:
> From looking at "hw/block/pflash_cfi01.c", it seems that the guest can
> interrogate the flash device about its size (nb_blocs is stored in
> cfi_table starting at 0x2D, and cfi_table can be queried by command 0x98
> in pflash_read()). So, if the gues
On 11/26/13 14:11, Markus Armbruster wrote:
> Laszlo Ersek writes:
>
>> On 11/25/13 16:32, Markus Armbruster wrote:
>>> Laszlo Ersek writes:
>>>
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,fo
On 11/26/13 13:36, Markus Armbruster wrote:
> Your stated purpose for multiple -pflash:
>
> This accommodates the following use case: suppose that OVMF is split in
> two parts, a writeable host file for non-volatile variable storage, and a
> read-only part for bootstrap and decompress
On 11/26/13 13:53, Markus Armbruster wrote:
> Thus, we grab *all* if=pflash drives for this purpose.
>
> Your stated use case wants just two.
>
> Hmm. Are we sure we'll never want to map an if=pflash device somewhere
> else?
No, I'm not sure.
Thanks
Laszlo
---
On 26 November 2013 11:43, Olivier Martin wrote:
> Hi Ryan/Leif,
>
>
>
> I was initially happy enough with the solution #4 and wanted to push your
> change to SVN. And yes, I can only be agree on the fact the EFI stub is the
> way we want to go to boot Linux kernel on a UEFI system.
>
> But I am
Hi Ryan/Leif,
I was initially happy enough with the solution #4 and wanted to push your
change to SVN. And yes, I can only be agree on the fact the EFI stub is the
way we want to go to boot Linux kernel on a UEFI system.
But I am not sure how the EFI stub will solve your problem.
Even with th
Thanks Ersek & Lin,
I will try to re-produce and fix it as soon as possible.
Jeff
-Original Message-
From: Gary Ching-Pang Lin [mailto:g...@suse.com]
Sent: Tuesday, November 26, 2013 6:06 PM
To: Laszlo Ersek
Cc: edk2-devel@lists.sourceforge.net; Fan, Jeff
Subject: Re: [edk2] SVN r14885 b
Jordan,
Got you! Thanks!
Jeff
-Original Message-
From: Justen, Jordan L
Sent: Tuesday, November 26, 2013 5:33 PM
To: Fan, Jeff; Ni, Ruiyu
Cc: edk2-devel@lists.sourceforge.net; Laszlo Ersek
Subject: OvmfPkg contributions - Re: [edk2] SVN r14885 breaks OVMF
On Tue, 2013-11-26 at 06:21 +01
On Mon, Nov 25, 2013 at 11:27:14PM +, Kinney, Michael D wrote:
> Wei,
>
> The PCD declaration in the DEC file declares the PCD type the PCD is
> allowed to have. For this specific PCD, you may want to allow it to
> be FixedAtBuild or PatahcbleInModule or Dynamic or DynamicEx. This
> provides
Hi Olivier,
Thanks for your mail.
I have a SerialPortLib which tries to configure Serial controller specific to
my board
(so *no* 'SerialPortLib' pointing to
'MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf'
in my DSC).
I am getting the UEFI firmware .. banner at the very start.
Sorry to not reply earlier, I was on holiday in the last two weeks.
If you do not see any output from the serial, ensure your are using the
appropriate 'SerialPortLib'.
Check in your DSC file, there is no 'SerialPortLib' pointing to
'MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf'.
The exercise of porting Undi EDK Intel(R) PRO/1000 Network Driver to ARM
EDK2 was looking interesting.
I had a quick try to get an idea of the effort. What I did:
1) Unpacked the archive under ArmPlatformPkg\Drivers\GigUndi
2) Create ArmPlatformPkg\Drivers\GigUndi\GigUndi.inf (see a
Laszlo,
I found if I specify "-m 1024" when running QEMU, it will crash. I am using
Windows version 0.13.0. Will try 1.16 tomorrow.
Thanks,
Ray
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, November 26, 2013 5:38 PM
To: edk2-devel@lists.sourceforge.net
On Tue, Nov 26, 2013 at 09:46:08AM +0100, Laszlo Ersek wrote:
> On 11/26/13 07:44, Gary Ching-Pang Lin wrote:
> > On Tue, Nov 26, 2013 at 06:21:21AM +0100, Laszlo Ersek wrote:
> >> Hi,
> >>
> >> as soon as Timer.efi is installed and the first timer interrupt is
> >> delivered, OVMF hangs with the V
On 11/26/13 09:46, Laszlo Ersek wrote:
> On 11/26/13 07:44, Gary Ching-Pang Lin wrote:
>> On Tue, Nov 26, 2013 at 06:21:21AM +0100, Laszlo Ersek wrote:
>>> Hi,
>>>
>>> as soon as Timer.efi is installed and the first timer interrupt is
>>> delivered, OVMF hangs with the VCPU spinning at 100%.
>>>
>>
On Tue, 2013-11-26 at 06:21 +0100, Laszlo Ersek wrote:
> as soon as Timer.efi is installed and the first timer interrupt is
> delivered, OVMF hangs with the VCPU spinning at 100%.
>
> I can see that SVN r14887 is the commit that directly switches the
> libraries that OvmfPkg uses.
>
> However, at
On 11/26/13 07:44, Gary Ching-Pang Lin wrote:
> On Tue, Nov 26, 2013 at 06:21:21AM +0100, Laszlo Ersek wrote:
>> Hi,
>>
>> as soon as Timer.efi is installed and the first timer interrupt is
>> delivered, OVMF hangs with the VCPU spinning at 100%.
>>
>> I can see that SVN r14887 is the commit that d
Hi Yi,
Thanks for reporting this issue.
Your fix looks good to SMBIOS module and no problem for UEFI boot, but
LegacyBiosDxe module in IntelFrameworkModulePkg assumes smbios table in
reserved memory currently and passes the SMBIOS pointer to CSM16, if we change
to runtime attribu
39 matches
Mail list logo
