[U-Boot] [PATCH v4 1/3] net: designware: fix descriptor layout and warnings on 64-bit archs

[Alexander Graf <agraf@suse.de>]

On 18.04.16 23:38, Beniamino Galvani wrote:
> On Mon, Apr 18, 2016 at 01:06:37PM +0200, Alexander Graf wrote:
>> Hmm, this is going to get very interesting with efi_loader support. By
>> default we allocate memory at the highest possible free address, so payloads
>> will probably (unless they specify limits) have their buffers above 32bit on
>> this platform. If we now deny any DMA to them, we basically break I/O
>> access.
> 
> I'm not familiar with efi_loader, but on this platform the physical
> RAM is within the 32bit memory range, so I don't think a workaround is
> needed. And I guess probably it's the same for the other 64bit ARM SoC
> using this driver.

So if RAM is always within the lower 32bits, then we don't have a problem.

> BTW, I see that another driver (sunxi_mmc) also truncates the upper 32
> bits of addresses on 64bit platforms. Maybe this issue should be
> addresses in a generic way?

The only 64bit sunxi platform (A64) also only has 32bit physical RAM
addresses.

>> Could you by any chance just use a bounce buffer?
> 
> Do you have any suggestions on how to do it? Are there any primitives
> in u-boot to request memory from low addresses?

Thinking about this I don't think we have the memory reservation
logistics to maintain a good bounce buffer. You could create a global
array in bss that you read to / write from, but I'm not sure it's really
worth it.

At the end of the day, if you know that your platform can only ever do
32bit DMA to a physical address range that's only 32bits, it's perfectly
ok IMHO.

We only have a problem if you have a platform that has RAM above 4G and
can only do DMA to 32bit addresses.


Alex