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