[U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[Alexander Graf]

> Am 11.05.2016 um 19:09 schrieb York Sun <york.sun at nxp.com>:
> 
>> On 05/11/2016 10:04 AM, Alexander Graf wrote:
>> 
>> 
>>>> Am 11.05.2016 um 18:33 schrieb York Sun <york.sun at nxp.com>:
>>>> 
>>>> On 05/11/2016 09:25 AM, Alexander Graf wrote:
>>>> While testing our shiny new EFI support, I stumbled across systems that
>>>> have disk I/O hardware that can only access the lower 32bits of our
>>>> physical address space.
>>>> 
>>>> This is not a problem when running with the normal U-Boot flow, since we
>>>> define all "pointers" that get in use in our environment, so we can just
>>>> put them inside the lower 32bits.
>>>> 
>>>> But when a higher level application such as an EFI payload comes across,
>>>> it doesn't know about these constraints. So we need to allocate bounce
>>>> buffers for the payload and use them instead.
>>> 
>>> Alexander,
>>> 
>>> The low 32-bit physical memory is required for this to work, isn't it? There was
>>> a discussion to move to high memory for LS2080 so the memory can be continuous
>>> for OS.
>> 
>> So how would that work in the non-efi case? Do you configure the smmu statically to give you an offset between device memory view and physical?
> 
> Alex,
> 
> We are still waiting for more thorough testing on all drivers. This was an
> effort to provide continuous memory for OS. As you know, only 2GB memory is
> available under 32-bit space. All other memory shows up at above 39-bit space.
> Limited tests proved Linux can boot with the high memory. However, some drivers
> may not be happy with the missing 32-bit memory space. The final call is not
> made yet.

Yes, I remember the discussion and I think it's a great idea. In Linux we shouldn't have any issue at all, since we have full SMMU support there, so a device can always just see everything inside its 32bit addressable space.

But in U-Boot things are not quite as clear to me. I don't think we configure any smmu mapping today, do we? So in that scenario, what's the plan to get it working? The simplest thing I could come up with were simple prepopulated iommu tables that just give us an offset, preferably one that allows us to just cut off the upper 32bits for addresses.


Alex