On Thu, 2016-02-18 at 18:02 +0100, Laszlo Ersek wrote:
> I briefly skimmed your enormous patch in your github repo -- I see that
> there are several changes to OvmfPkg/QemuVideoDxe. Some of them seem to
> relate directly to the PciIo change (= address translation), while other
> changes in the driv
On Thu, 2016-02-18 at 18:02 +0100, Laszlo Ersek wrote:
>
> with Ray's change in the generic PCI bus driver, *must* all PciIo-based
> device drivers be updated? Is this a (bug-)compatible change, or does it
> regress existing drivers (perhaps by triggering their hidden bugs)?
I wouldn't expect exi
code review. (Ping me if I forget).
Cheers,
Ben.
> Regards,
> Ray
>
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Thursday, February 18, 2016 11:21 AM
> To: Ni, Ruiyu ; edk2-de...@ml01.01.org
> Cc: Andrew
sSpace);
+if (EFI_ERROR (Status)) {
+ FreePool(AddressSpace);
+ return Status;
+}
+
+//
// put the checksum
//
End = (EFI_ACPI_END_TAG_DESCRIPTOR *) (AddressSpace + 1);
View
> Contributed-under: TianoCore Contribution Agreement 1.0
On Fri, 2015-09-18 at 17:03 +0200, Laszlo Ersek wrote:
> Cc'ing Ben
Thanks, I saw it :) I just got caught up with a bunch of other things
and haven't had a chance to look more closely.
I got legal approval to release code, so I'm hoping sometime in the
next few weeks, to push out on github a slig
is an MMIO mapping
or a DMA mapping ... I to looks like MMIO to me in which case it has
strictly nothing to do with IoMap/AllocateBuffer
Cheers,
Ben
> Thanks and Regards,
> Shaveta
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
On Sat, 2015-09-12 at 11:20 -0700, Andrew Fish wrote:
> That is platform dependent. These buffers are for doing DMA. On x86
> normal memory just works, for ARM you needed an uncached buffer, and
> you have to do some cache management to maintain coherency.
On *some* ARM :-) It's my undertsanding
On Wed, 2015-09-02 at 12:25 +0200, Laszlo Ersek wrote:
> > Interesting. I have something more/less working with the IntelBDS
> > (though ugly) and not at all with MdeModulePkg but as I said, I
> > mostly
> > copy/pasted "stuff" around without quite understanding what I was
> > doing
> > at this st
On Wed, 2015-09-02 at 11:33 +0200, Laszlo Ersek wrote:
> On 09/02/15 01:01, Ard Biesheuvel wrote:
> > On 2 September 2015 at 00:32, Benjamin Herrenschmidt <
> > b...@au1.ibm.com> wrote:
> > > On Wed, 2015-08-26 at 11:59 +0200, Ard Biesheuvel wrote:
> > > &g
On Wed, 2015-09-02 at 01:01 +0200, Ard Biesheuvel wrote:
> Excellent question.
>
> If you are doing a new port, there is no reason to use the old Intel
> BDS and you are better off supporting only the new universal BDS.
Thanks !
Cheers,
Ben.
> For the ARM platforms, I think we should move to t
On Wed, 2015-08-26 at 11:59 +0200, Ard Biesheuvel wrote:
> This adds support for the Intel BDS, by introducing a define
> 'USE_ARM_BDS' which defaults to TRUE, and can be overridden on
> the build command line.
Out of curiosity (still in the process of getting my head around the
BDS stuff for my P
en easier of the allocation HOBs were sorted :)
Cheers,
Ben.
> Thanks
> Liming
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Thursday, August 27, 2015 4:50 AM
> To: Gao, Liming; Tian, Feng
> Cc: Kinney, Michael D; edk2-dev
#x27;t be used since it will have allocations in it or at
least the PhitHob).
So we may get away not doing 3) but again, I lack visibility of what's
happening in practice on other architectures with their memory layout
to make a judgment call.
Cheers,
Ben.
> Thanks
> Liming
> -
On Wed, 2015-08-26 at 01:53 +, Tian, Feng wrote:
> Hi, Ben & Andrew
>
> The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors
> that describe the current configuration of the BARs of the PCI
> controller.
>
> What I understood is the returned value of GetBarAttributes() is a
>
On Tue, 2015-08-25 at 19:37 -0700, Andrew Fish wrote:
> But it looks like the default in ACPI is a CPU (processor-relative)
> address. Thus if the mapping is not 1:1 "Address Translation Offset”
> is the offset for the bus view.
>
> I see from the PCI bus driver that there is not a path to return
(Argh, I keep sending these from my IBM address which isn't the one on
the list. Sorry Andrew for the duplicates).
On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote:
>
> > So if we stick to the definition of GetBarAttributes() only
> > returning a
> > BAR value, then it's impossible to implem
On Wed, 2015-08-26 at 07:58 +1000, Benjamin Herrenschmidt wrote:
> Another one is the UFS Host Controller protocol though it's local to
> EDK2 thankfully and not part of the spec. Here too, the protocol
> definition and underlying implementation rely on direct access.
>
> I
On Tue, 2015-08-25 at 14:45 -0700, Andrew Fish wrote:
> Well the GOP returns a FrameBuffer, so that address needs to be
> adjusted. So that seems to be the bug in the spec. I’ll bring this up
> to the UEFI Forum.
>
> But I think for the non FrameBuffer case it would be better to fix
> the drivers
On Tue, 2015-08-25 at 14:45 -0700, Andrew Fish wrote:
>
> Well the GOP returns a FrameBuffer, so that address needs to be
> adjusted. So that seems to be the bug in the spec. I’ll bring this up
> to the UEFI Forum.
>
> But I think for the non FrameBuffer case it would be better to fix
> the driv
On Wed, 2015-08-26 at 07:18 +1000, Benjamin Herrenschmidt wrote:
>
> > I think you have it backwards. The UEFI spec abstracts PCI
> > properly,
> > and drivers are implemented incorrectly, but they work due to x86
> > PC
> > assumptions.
> >
> > G
On Tue, 2015-08-25 at 06:47 -0700, Andrew Fish wrote:
> > Sadly it doesn't seem like the UEFI spec caters well to that non
> > -1:1
> > mapping (which is quite common outside of the x86 world), and
> > doesn't
> > really sat what GetBarAttributes() is supposed to return. However,
> > practically,
Hi !
I have a situation where the mapping from the CPU address space to the
PCI MMIO space isn't 1:1
To give an example, I have, let's say, a 2G MMIO window to PCI, which
can generate PCI addresses 0x8000_..0x_ by accessing CPU
address 0x100_8000_..0x100__.
So far, I have
> Limin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of Benjamin Herrenschmidt
> Sent: Saturday, August 22, 2015 12:35 PM
> To: Tian, Feng
> Cc: Kinney, Michael D; edk2-devel@lists.01.org; Laszlo Ersek; Andrew
> Fish
>
On Mon, 2015-08-10 at 16:18 -0700, Andrew Fish wrote:
> Laszlo and I are not the maintainers for this code.
> https://github.com/tianocore/edk2/blob/master/Maintainers.txt <
> https://github.com/tianocore/edk2/blob/master/Maintainers.txt>
>
> But it does feel like the assumption in the DXE Core
On Tue, 2015-08-11 at 11:55 +0200, Laszlo Ersek wrote:
>
> So practically:
> (1) if the memory resource descriptor that the free page area of the
> permanent PEI RAM comes from has enough room "above" the permanent PEI
> RAM, then the DXE core is tentatively targeted there.
Yes and it will ignore
On Mon, 2015-08-10 at 16:18 -0700, Andrew Fish wrote:
>
>
> Laszlo and I are not the maintainers for this code.
> https://github.com/tianocore/edk2/blob/master/Maintainers.txt
>
>
> But it does feel like the assumption in the DXE Core is not implied by
> the PI Specifications.
Thanks, I'm us
On Tue, 2015-08-11 at 08:08 +1000, Benjamin Herrenschmidt wrote:
.../...
> That means that if I want to reserve memory elsewhere in the system, I
> need to either:
>
> - Make sure that chunk of memory is not covered by a memory resource
> descriptor HOB, or at least one th
On Mon, 2015-08-10 at 14:38 -0700, Andrew Fish wrote:
>
>
> The CoreInitializeMemoryServices()
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Gcd/Gcd.c,
> is going to start allocating from the resource descriptor HOB that contains
> the PHIT range. If you are actually ru
On Mon, 2015-08-10 at 20:14 +0200, Laszlo Ersek wrote:
> On 08/10/15 18:46, Andrew Fish wrote:
> >> Essentially, I am on a platform/architecture which feeds a flat
> >> device-tree to EDK and I need to honor the input reserved regions
> >> as they cover bits of memory either already used by the HW
On Mon, 2015-08-10 at 09:46 -0700, Andrew Fish wrote:
>
>
> You can’t pass in an allocation, so you can only control things from
> the GCD point of view. See CoreInitializeMemoryServices() in
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
>
> And that is done via
On Sun, 2015-08-09 at 15:54 -0500, Scott Duplichan wrote:
> 6) TimerInterruptHandler calls RestoreTPL. RestoreTPL executes a loop for
>"Dispatch any pending events". Interrupts are re-enabled if all pending
>event have TPL < HIGH. CoreDispatchEventNotifies calls CoreAcquireEventLock
>wh
Hi !
Yet another somewhat newbie question, I apologize if I missed the right
piece of doc...
I found some kind of disconnect between the core idea of TPL and the
interrupt enable state of the processor.
The core will enable or disable processor interrupts based on TPL state
changes.
However the
On Sat, 2015-08-08 at 17:12 +0200, Laszlo Ersek wrote:
> If that's indeed your point, then maybe it will help to look at the call
> tree "context" in the DXE core, where this function --
> CoreInitializeMemoryServices() -- is called from:
>
> DxeMain()[MdeModulePkg/Core/D
On Sat, 2015-08-08 at 08:56 -0700, Andrew Fish wrote:
> If you really need to punch holes in the memory map, then you can use
> resource descriptors.
Yes, I do need to punch holes in there, Laszlo explanation (which I
haven't fully digested yet) implies that using allocation hobs should
work whic
On Sat, 2015-08-08 at 17:12 +0200, Laszlo Ersek wrote:
> > What am I missing ? :-)
>
> I think you were missing the conceptual hierarchy between the GCD
> memory
> space map and the UEFI memory map, and which HOBs produced in PEI
> (resource vs. allocation), and which services called in DXE and la
Hi !
I'm still trying to get my head around the internals of EDK here so bear
with me if there's an obvious answer that I missed ... :-)
I'm trying to understand how I can properly reserve bits of memory from
my PrePei or Pei so that DXE won't stomp on them.
To simplify the discussion, let's ass
36 matches
Mail list logo
