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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot