Hi Rafael,
Yes, my USB device format is FAT32.
I try to compare EDKII.UP1.SR1 with UDK2014. and I found
UDk2014+ ShellPkg of EDKII.UP1.SR1 can be boot to shell normally.
Thanks
James Chen
From: Rafael Machado [mailto:rafaelrodrigues.mach...@g
Laszlo:
The patch is good.
Reviewed-by: Liming Gao
Thanks
Liming
-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: Thursday, November 27, 2014 9:37 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH v4 2/2] MdePkg: UefiScsiLib: do not encode LUN
Sergey,
I googled this question, 2-4TB disk for MBR could exist and be identified by
some OSes. Please see http://www.rodsbooks.com/gdisk/workarounds.html.
But I agree this case is more literal rather than practical.
I think a better solution could be:
UINT64 EndingLBA;
EndingLBA = StartingL
On 27 November 2014 at 23:34, Laszlo Ersek wrote:
> Thanks for the hint, I was actually wondering if some official registry
> existed for the node names and types. So yeah I'll attempt to get it in
> there. (Once I find the docs in question in the kernel :))
Documentation/devicetree is probably a
On 11/28/14 00:28, Peter Maydell wrote:
> On 27 November 2014 at 23:18, Laszlo Ersek wrote:
>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
>> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
>> board.
>>
>> The mmio register block of fw_cfg is adve
On 27 November 2014 at 23:18, Laszlo Ersek wrote:
> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
> board.
>
> The mmio register block of fw_cfg is advertized in the device tree. As
> base address we
We have all the required pieces in place. Let's call
SetBootOrderFromQemu() in PlatformBdsPolicyBehavior().
We disable OFW-to-UEFI device path fragment translation for virtio-pci,
and enable it only virtio-mmio at this time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: L
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware
device paths:
virtio-blk: /virtio-mmio@0a003c00/disk@0,0
virtio-scsi disk: /virtio-mmio@0a003a00/channel@0/disk@2,3
virtio-net NIC: /virtio-mmio@0a003e00/ethernet-phy@0
The new transla
Installing VenHw() device paths with this GUID, for the virtio-mmio
transports that we detect, enables other modules to recognize those
VenHw() nodes. (Note that the actual value doesn't change.)
In addition, to avoid reusing GUIDs in unrelated contexts, detach the
driver's FILE_GUID from its prev
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like"
OFW device path fragments, let's turn the currently exclusive "PCI-like"
translation into "just one" of the possible translations.
- Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is
tightly coupled to "
The default value of this PCD (in "IntelFrameworkModulePkg.dec")
identifies the "old shell" from EdkShellBinPkg. Our build includes the
"new" shell from ShellBinPkg/UefiShell/UefiShell.inf; let's specify the
FILE_GUID of that.
Otherwise, no boot option will be generated for the Shell application.
and rebase OvmfPkg's PlatformBdsLib on the standalone library.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
| 3 +--
OvmfPkg/Library/QemuBootOrderLib/QemuBootOrder
The series
- adds a DTB- and MMIO-based fw_cfg client library to the
ArmVirtualizationQemu platform (patches #1 and #2),
- makes OvmfPkg's OpenFirmware to UEFI devpath translation logic
reusable for the ArmVirtualizationQemu platform, making the virtio-pci
specific bits conditional (patches
The OpenFirmware device path nodes that QEMU generates for virtio-mmio
transports contain 64-bit hexadecimal values (16 nibbles) -- the base
addresses of the register blocks. In order to parse them soon,
ParseUnitAddressHexList() must parse UINT64 values.
Call sites need to be adapted, as expected
In the next patch(es) we'll customize the PlatformBdsLib instance used by
ArmVirtualizationQemu.dsc. Let's clone it first verbatim from
ArmPlatformPkg/Library/PlatformIntelBdsLib, changing only its FILE_GUID.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
We'll use them in board-specific code in the next patch.
Signed-off-by: Laszlo Ersek
---
include/hw/nvram/fw_cfg.h | 3 +++
hw/nvram/fw_cfg.c | 2 --
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index 56e1ed7..286d94
fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
board.
The mmio register block of fw_cfg is advertized in the device tree. As
base address we pick 0x0902, which conforms to the comment preceding
"a15
Qemu's firmware configuration interface consists of two MMIO registers, a
16-bit selector and an 8-bit data register. Parse their addresses and
verify their sizes from the DTB, and expose them to the rest of DXE by
storing them in dynamic PCDs.
Contributed-under: TianoCore Contribution Agreement 1
Soon there will be more than one modules (in separate packages) that need
to have an understanding about the GUID used in the VenHw() device path
nodes that describe virtio-mmio transports. Define such a GUID explicitly.
Preserve the current value (which happens to be the FILE_GUID of
ArmPlatformP
In PlatformBdsPolicyBehavior() we should follow the same pattern as in
OvmfPkg's: after the consoles are connected,
- connect all drivers and devices,
- enumerate all boot options,
- enter the Intel BDS FrontPage if the user presses a key different from
Enter.
We set the countdown to 3 seconds,
After reviewing OvmfPkg's use of its own QemuFwCfgLib instances, it is
clear that its only pre-DXE fw_cfg dependency concerns S3 support (the
QemuFwCfgS3Enabled() call in "PlatformPei/Platform.c").
For ARM guests, S3 is in the distant future, but we can see several
shorter term applications for fw
A number of ARM guest firmware features [1] would like to rely on a
"fw_cfg-like conduit device" [2], so let's add just that.
[1] boot order, ACPI linker/loader, '-kernel' booting, maybe SMBIOS
tables, etc
[2] http://thread.gmane.org/gmane.comp.emulators.qemu/304059/focus=306834
Thanks,
Laszl
Hi,
this message is meant as a short, cross-posted thread starter, so that
both qemu- and edk2-side comments can be kept in one thread. I'll follow
up with two series:
- the first small series for qemu adds fw_cfg to the arm "virt" machine
type in qemu, automatically exposing the "bootorder" fw
> On Nov 27, 2014, at 3:13 AM, David Cox wrote:
>
> Hi,
>
> Are library constructors invoked once as part of image initialise? And if so
> are they always invoked on every boot warm/cold etc.?
>
Yes the library constructors are invoked as part of the image initialization.
The entry point
Yes, I understood. I just think that all values must be UINT32 because I can't
imaging that EndLBA will be > Uint32Max. It will be bug for any disk
software/drivers.
On 27.11.2014, at 11:55, Tian, Feng wrote:
> Sergey, You misunderstand what I meant.
>
> I am talking about EndingLBA rather t
Hi,
Are library constructors invoked once as part of image initialise? And if so
are they always invoked on every boot warm/cold etc.?
Or are library constructors invoked every time a user component starts using
the library? Like C++ constructors, an instance?
Example Inf:
[Defines]
...
C
Hi James Chen
Just to confirm. Is the USB device you are using to the new shell formatted
as FAT32 ?
Thanks
Rafael R. Machado
2014-11-27 0:20 GMT-02:00 James Chen :
> Hi Administrator,
>
> I built shell.efi with EDKII.SR1.UP1.P1
> and it can boot to shell with fo
Sergey, You misunderstand what I meant.
I am talking about EndingLBA rather than StartingLBA and SizeInLBA. EndingLBA =
StartingLBA + SizeInLBA. So EndingLBA could be > 0x and up to 2T space.
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Thursday, November 27, 2014 16:16
To: edk2-de
Feng,
IndustryStandard assumes UINT32
typedef struct {
UINT8 BootIndicator;
UINT8 StartHead;
UINT8 StartSector;
UINT8 StartTrack;
UINT8 OSIndicator;
UINT8 EndHead;
UINT8 EndSector;
UINT8 EndTrack;
UINT8 StartingLBA[4];
UINT8 SizeInLBA[4];
} MBR_PARTITION_RECORD;
Serge
29 matches
Mail list logo
