> The LinuxLoader is a poorly maintained hack, and it is badly broken on
AARCH64
I'm actually just using the shutdown code from linux loader. I wrote my
own, very complete loader which does definitely work in terms of correct
loading and argument passing.
> Does the system have an L2 cache which m
On 11/04/15 23:22, liang yan wrote:
> Hello, Laszlo,
>
> (1)I am trying to add ivshmem device(PCI device with big memory) to my
> aarch64 vm.
> So far, I could find device information from vm. But it seems vm did not
> create
> correct resource file for this device. Do you have any idea that this
On 2 September 2016 at 20:23, Laszlo Ersek wrote:
> On 09/02/16 20:15, Ard Biesheuvel wrote:
>> Now that Laszlo's virtio-gpu-pci series has removed the last remaining
>> obstacle,
>> we can get rid of the special PciHostBridgeDxe implementation in ArmVirtPkg,
>> and move to the generic one. On AA
On 2 September 2016 at 21:45, Michael Zimmermann
wrote:
> If I understand this correctly this is just some MMU feature, right?
> I'm talking about a pure ARM(with atag's) linux kernel which is not UEFI
> aware.
>
> Also the LinuxLoader disables almost everything(MMU, caches, it calls
> exitbootser
If I understand this correctly this is just some MMU feature, right?
I'm talking about a pure ARM(with atag's) linux kernel which is not UEFI
aware.
Also the LinuxLoader disables almost everything(MMU, caches, it calls
exitbootservices etc).
I really can't explain technically what UEFI could have
On 09/02/16 15:08, Michael Zimmermann wrote:
> Hi,
>
> a friend of mine works with a hacked Luma WP device. he can already boot
> Android by replacing UEFI with a linux bootloader.
> What would be nice however is using UEFI's LinuxLoader. The problem with
> that seems to be that even after ExitBoo
On 09/02/16 21:18, Leif Lindholm wrote:
> On Fri, Sep 02, 2016 at 07:45:26PM +0100, Ard Biesheuvel wrote:
I agree that fixing the branch now would be nice. I just don't
understand why fixing BaseMemoryLibStm in place is not a better
solution, especially if we are nuking it anywa
On 09/02/16 20:15, Ard Biesheuvel wrote:
> Now that Laszlo's virtio-gpu-pci series has removed the last remaining
> obstacle,
> we can get rid of the special PciHostBridgeDxe implementation in ArmVirtPkg,
> and move to the generic one. On AArch64, this will allow us to perform DMA
> above
> 4GB w
On Fri, Sep 02, 2016 at 07:45:26PM +0100, Ard Biesheuvel wrote:
> >>
> >> I agree that fixing the branch now would be nice. I just don't
> >> understand why fixing BaseMemoryLibStm in place is not a better
> >> solution, especially if we are nuking it anyway next week. That way,
> >> we have to ch
> On 2 sep. 2016, at 19:32, Leif Lindholm wrote:
>
> On Fri, Sep 02, 2016 at 07:11:02PM +0100, Ard Biesheuvel wrote:
Added the fact that the Stm is not in great shape, I would really
prefer to get rid of it rather than 'promote' it to the standard ARM
implementation. Note that we
On Fri, Sep 02, 2016 at 07:11:02PM +0100, Ard Biesheuvel wrote:
> >> Added the fact that the Stm is not in great shape, I would really
> >> prefer to get rid of it rather than 'promote' it to the standard ARM
> >> implementation. Note that we will need another round of updates to the
> >> platform
Wire up the FdtPciHostBridgeLib introduced in the previous patch
to the generic PciHostBridgeDxe implementation, and drop the special
ArmVirtPkg version. The former's dependency on gEfiCpuIo2ProtocolGuid
is satisfied by adding ArmPciCpuIo2Dxe.inf as well, and adding the PCD
gArmTokenSpaceGuid.PcdPc
If the pci-host-ecam-generic DT node describes a 64-bit MMIO region,
account for it in the PCI_ROOT_BRIDGE description that we return to
the generic PciHostBridgeDxe implementation, which will be able to
allocate BARs from it without any further changes.
Contributed-under: TianoCore Contribution A
Add handling of the PcdPciIoTranslation PCD, so that modules that include
this library via NULL resolution are guaranteed that it will be set before
they reference it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
Ref: https://tia
Now that Laszlo's virtio-gpu-pci series has removed the last remaining obstacle,
we can get rid of the special PciHostBridgeDxe implementation in ArmVirtPkg,
and move to the generic one. On AArch64, this will allow us to perform DMA above
4GB without bounce buffering, and use 64-bit MMIO BARs alloc
Implement PciHostBridgeLib for DT platforms that expose a PCI root bridge
via a pci-host-ecam-generic DT node. The DT parsing logic is copied from
the PciHostBridgeDxe implementation in ArmVirtPkg, with the one notable
difference that we don't set some of the legacy PCI attributes for IDE
and VGA I
Setting the linux,pci-probe-only was intended to align OSes booting via
DT with OSes booting via ACPI in the way they honor the PCI configuration
performed by the firmware. However, ACPI on arm64 does not currently honor
the firmware's PCI configuration, and the linux,pci-probe-only completely
prev
On 2 September 2016 at 19:05, Leif Lindholm wrote:
> On Fri, Sep 02, 2016 at 05:07:48PM +0100, Ard Biesheuvel wrote:
>> > This isn't a proposed alternative to your patchset, this is an
>> > alternative to reverting all of the other BaseMemoryLib changes.
>> > I'm happy to throw it away next week i
Hi Feng,
Some Nvme devices returns EFI_DEVICE_ERROR for the SCT test code ( when the
buffer passed with 10 bytes) and that creates failure in the SCT report.
Some Nvme devices returns EFI_SUCCESS also.
All the devices return EFI_SUCCESS if the we send the buffer size as "Memory
Page size Mini
On Fri, Sep 02, 2016 at 05:07:48PM +0100, Ard Biesheuvel wrote:
> > This isn't a proposed alternative to your patchset, this is an
> > alternative to reverting all of the other BaseMemoryLib changes.
> > I'm happy to throw it away next week if we can get something better in
> > by then.
> >
> >> Th
On 09/02/16 18:26, Ard Biesheuvel wrote:
> On 2 September 2016 at 17:13, Laszlo Ersek wrote:
>> On 09/02/16 17:27, Laszlo Ersek wrote:
>>> On 09/02/16 16:58, Ard Biesheuvel wrote:
(on the road atm, will reply in full later)
> On 2 sep. 2016, at 14:09, Laszlo Ersek wrote:
>>>
> (
On 2 September 2016 at 17:13, Laszlo Ersek wrote:
> On 09/02/16 17:27, Laszlo Ersek wrote:
>> On 09/02/16 16:58, Ard Biesheuvel wrote:
>>> (on the road atm, will reply in full later)
>>>
On 2 sep. 2016, at 14:09, Laszlo Ersek wrote:
>>
(2) aarch64 KVM, using virtio-gpu-pci and USB 2 key
On 09/02/16 17:27, Laszlo Ersek wrote:
> On 09/02/16 16:58, Ard Biesheuvel wrote:
>> (on the road atm, will reply in full later)
>>
>>> On 2 sep. 2016, at 14:09, Laszlo Ersek wrote:
>
>>> (2) aarch64 KVM, using virtio-gpu-pci and USB 2 keyboard and
>>> tablet. I actually booted a Fedora 24 guest
On 2 September 2016 at 16:23, Leif Lindholm wrote:
> On Fri, Sep 02, 2016 at 04:02:44PM +0100, Ard Biesheuvel wrote:
>> > On 2 sep. 2016, at 15:29, Leif Lindholm wrote:
>> >
>> > Recent changes to the BaseMemoryLib implementations in MdePkg,
>> > and other changes dependent on these, left all ARM
On Fri, Sep 02, 2016 at 04:53:19PM +0200, Laszlo Ersek wrote:
> > I believe the series needs a few more (small) patches to update
> > the library resolutions (and other references) in DSC files that
> > become invalid due to the move:
> >
> > $ git grep ArmPkg/Library/BaseMemoryLibStm/BaseMemoryLi
> On Sep 2, 2016, at 8:57 AM, Leif Lindholm wrote:
>
> On Fri, Sep 02, 2016 at 03:49:03PM +, Kinney, Michael D wrote:
>> Moving this library into MdePkg looks good to me along with the
>> addition of the 2 new BaseMemoryLib APIs.
>>
>> Minor issues in ArmPkg.dsc, ArmPkg.dsc.inc not updating
On Fri, Sep 02, 2016 at 03:49:03PM +, Kinney, Michael D wrote:
> Moving this library into MdePkg looks good to me along with the
> addition of the 2 new BaseMemoryLib APIs.
>
> Minor issues in ArmPkg.dsc, ArmPkg.dsc.inc not updating the
> Copyright to 2016.
Ah, OK, I could fix that before pus
Leif,
Moving this library into MdePkg looks good to me along with the addition of the
2 new BaseMemoryLib APIs.
Minor issues in ArmPkg.dsc, ArmPkg.dsc.inc not updating the Copyright to 2016.
Reviewed-by: Michael Kinney
Mike
> -Original Message-
> From: Leif Lindholm [mailto:leif.li
On 09/02/16 16:58, Ard Biesheuvel wrote:
> (on the road atm, will reply in full later)
>
>> On 2 sep. 2016, at 14:09, Laszlo Ersek wrote:
>> (2) aarch64 KVM, using virtio-gpu-pci and USB 2 keyboard and
>> tablet. I actually booted a Fedora 24 guest with this, and in the
>> guest, everything work
On Fri, Sep 02, 2016 at 04:02:44PM +0100, Ard Biesheuvel wrote:
> > On 2 sep. 2016, at 15:29, Leif Lindholm wrote:
> >
> > Recent changes to the BaseMemoryLib implementations in MdePkg,
> > and other changes dependent on these, left all ARM* platforms
> > unbuildable. To avoid this sort of thing
> On 2 sep. 2016, at 15:29, Leif Lindholm wrote:
>
> Recent changes to the BaseMemoryLib implementations in MdePkg,
> and other changes dependent on these, left all ARM* platforms
> unbuildable. To avoid this sort of thing in the future, move
> the ARM* BaseMemoryLib implementations to the same
(on the road atm, will reply in full later)
> On 2 sep. 2016, at 14:09, Laszlo Ersek wrote:
>
>> On 08/31/16 19:59, Ard Biesheuvel wrote:
>> Now that Laszlo's virtio-gpu-pci series has removed the last remaining
>> obstacle,
>> we can get rid of the special PciHostBridgeDxe implementation in Ar
On 09/02/16 16:48, Laszlo Ersek wrote:
> On 09/02/16 16:29, Leif Lindholm wrote:
>> The recent addition, and use, of new functions IsZeroGuid/IsZeroBuffer
>> caused all ARM/AARCH64 platforms to stop building. The oversight was
>> helped by the ARM implementation residing in ArmPkg rather than in
>>
On 09/02/16 16:29, Leif Lindholm wrote:
> The recent addition, and use, of new functions IsZeroGuid/IsZeroBuffer
> caused all ARM/AARCH64 platforms to stop building. The oversight was
> helped by the ARM implementation residing in ArmPkg rather than in
> MdePkg with all of the others.
>
> Move Bas
Recent changes to the BaseMemoryLib implementations in MdePkg,
and other changes dependent on these, left all ARM* platforms
unbuildable. To avoid this sort of thing in the future, move
the ARM* BaseMemoryLib implementations to the same locations
as the other ones.
Contributed-under: TianoCore Con
On Fri, Sep 02, 2016 at 04:18:11PM +0200, Laszlo Ersek wrote:
> > If we're not doing that, let's do the thing that will reduce the
> > likelihood of this breaking again.
> > In the interest of speeding this up, I would propose to wait with
> > Ard's latest set (which deserves and is likely to see s
From: Ard Biesheuvel
BaseMemoryLib has recently been extended with an API function
IsZeroBuffer(), so copy the default implementation into BaseMemoryLibStm
as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
.../Library
From: Ard Biesheuvel
BaseMemoryLib has recently been extended with an API function
IsZeroGuid(), so copy the default implementation into BaseMemoryLibStm
as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
MdePkg/Librar
The recent addition, and use, of new functions IsZeroGuid/IsZeroBuffer
caused all ARM/AARCH64 platforms to stop building. The oversight was
helped by the ARM implementation residing in ArmPkg rather than in
MdePkg with all of the others.
Move BaseMemoryLibStm across to MdePkg to reduce risk of sim
On 09/02/16 15:01, Leif Lindholm wrote:
> On Fri, Sep 02, 2016 at 01:33:21PM +0200, Laszlo Ersek wrote:
>>> Maybe this is a good point at which to move these into MdePkg, in the
>>> hope that the ARM versions won't be overlooked in future API
>>> revisions?
>>
>> I strongly suggest / request that y
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
b/UefiCpuPkg/Library/Mt
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 237 ---
1 file changed, 80 insertions(+), 157 deletions(-)
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
b/UefiCpuPkg/Lib
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 55 +---
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
b/UefiCpuPkg/Libr
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
b/UefiCpuPkg/Library/MtrrLib/MtrrL
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Include/Library/MtrrLib.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/UefiCpuPkg/Include/Library/MtrrLib.h
b/UefiCpuPkg/Include/Library/MtrrLib.h
index a769279..
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
b/UefiCpuPkg/Library/MtrrLib/MtrrL
The new algorithm finds out the most optimal MTRR solution for
current memory type settings.
The algorithm can guarantee there is really no solution if it
reports MTRRs are not enough for the current memory type settings.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
index 380
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c
b/UefiCpuPkg/Library/MtrrLib/Mt
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jeff Fan
---
UefiCpuPkg/Include/Library/MtrrLib.h | 16
UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 6 +++---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/UefiCpuPkg/Include/Libra
The patch sets enhances MtrrLib to find out the most optimal MTRR solution
for a given memory type setting.
Additionally, the patch sets refine the source code to use the defitions
in Register/Msr.h and Register/CpuId.h.
Ruiyu Ni (10):
UefiCpuPkg/MtrrLib: Correct typo in comments and remove TABs
On 09/02/16 15:09, Laszlo Ersek wrote:
> (4) This is for the longer term, but now that we have 64-bit MMIO
> aperture, we should include OvmfPkg/IncompatiblePciDeviceSupportDxe
> in ArmVirtQemu (please see commit 855743f71774). The circumstances
> described in the commit message now apply to ArmVi
On 08/31/16 19:59, Ard Biesheuvel wrote:
> Now that Laszlo's virtio-gpu-pci series has removed the last remaining
> obstacle,
> we can get rid of the special PciHostBridgeDxe implementation in ArmVirtPkg,
> and move to the generic one. On AArch64, this will allow us to perform DMA
> above
> 4GB w
Hi,
a friend of mine works with a hacked Luma WP device. he can already boot
Android by replacing UEFI with a linux bootloader.
What would be nice however is using UEFI's LinuxLoader. The problem with
that seems to be that even after ExitBootServices, booting linux from
addresses previously alloca
On Fri, Sep 02, 2016 at 01:33:21PM +0200, Laszlo Ersek wrote:
> > Maybe this is a good point at which to move these into MdePkg, in the
> > hope that the ARM versions won't be overlooked in future API
> > revisions?
>
> I strongly suggest / request that your (good) suggestion be implemented
> as a
To follow PI1.4a, BaseTools has be updated to fix artificial limitation of
SkuId range.
This patch is to update PCD database structure definition to match BaseTools.
Note: The source code and BaseTools need to be upgraded at the same time,
and if they are not upgraded at the same time, build erro
From: Yonghong Zhu
Current BaseTools follow previous PI spec to use UINT8 for SkuId, to
follow PI1.4a, BaseTools need to be updated to fix artificial limitation
of PCD SkuId range.
This patch is to update BaseTools to use UINT64 for SkuId, since the
PCD database structure needs to be naturally a
Current BaseTools follow previous PI spec to use UINT8 for SkuId, to
follow PI1.4a, BaseTools need to be updated to fix artificial limitation
of PCD SkuId range.
BaseTools is updated to use UINT64 for SkuId, since the PCD database
structure needs to be naturally aligned, the PCD database structure
Now that ArmPkg's BaseMemoryLib implementation is broken due to upstream
API changes, now is a good time to move to the MdePkg versions.
So add AARCH64 support to both BaseMemoryLib (generic C) and
BaseMemoryLibOptDxe (accelerated). The former can be used anywhere, the
latter only in places where
This adds AARCH64 support to BaseMemoryLibOptDxe, based on the cortex-strings
library. All string routines are accelerated except ScanMem16, ScanMem32,
ScanMem64 and IsZeroBuffer, which can wait for another day. (Very few
occurrences exist in the codebase)
Contributed-under: TianoCore Contribution
Since the default BaseMemoryLib should be callable from any context,
including ones where unaligned accesses are not allowed, it implements
InternalCopyMem() and InternalSetMem() using byte accesses only.
However, especially in a context where the MMU is off, such narrow
accesses may be disproporti
On 08/31/16 14:48, Leif Lindholm wrote:
> On Wed, Aug 31, 2016 at 10:07:30AM +0100, Ard Biesheuvel wrote:
>> The BaseMemoryLib API has recently been extended with IsZeroGuid() and
>> IsZeroBuffer(), so copy the generic implementations into the ArmPkg version
>> of this library.
>
> Maybe this is a
On 08/31/16 19:59, Ard Biesheuvel wrote:
> +if (!EFI_ERROR (Status) && RegSize == 2 * sizeof(UINT64)) {
Before you commit this patch, please insert a space character between
"sizeof" and "(".
Reviewed-by: Laszlo Ersek
Please hold on for a little while before committing the series, I'd like
Hi Mike,
On 07/06/16 20:52, Kinney, Michael D wrote:
> Laszlo,
>
> Good timing. I was going to send a status update today.
>
> We are working diligently to get Bugzilla online for all bugs. There
> are a few logistics that are still being worked this week related to
> an email list for bug s
On 08/31/16 19:59, Ard Biesheuvel wrote:
> @@ -308,8 +329,21 @@ PciHostBridgeGetRootBridges (
>mRootBridge.Io.Limit = IoBase + IoSize - 1;
>mRootBridge.Mem.Base = Mmio32Base;
>mRootBridge.Mem.Limit = Mmio32Base + Mmio32Size - 1;
> - mRootBridge.Me
On 08/31/16 19:59, Ard Biesheuvel wrote:
> Implement PciHostBridgeLib for DT platforms that expose a PCI root bridge
> via a pci-host-ecam-generic DT node. The DT parsing logic is copied from
> the PciHostBridgeDxe implementation in ArmVirtPkg, with the one notable
> difference that we don't set th
On 2 September 2016 at 07:37, Tian, Feng wrote:
> Reviewed-by: Feng Tian
>
> Thanks
> Feng
>
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, September 2, 2016 2:26 PM
> To: edk2-devel-01 ; Tian, Feng
> ; Zeng, Star
> Cc: Leif Lindholm ; Ard
67 matches
Mail list logo
