On 2/25/22 12:37, Mark Kettenis wrote:
From: Fabio Estevam festevam@gmail.com Date: Fri, 25 Feb 2022 08:12:58 -0300
Hi Tim,
On Thu, Feb 24, 2022 at 6:46 PM Tim Harvey tharvey@gateworks.com wrote:
Fabio,
No, that commit is 'not' in v2021.07. Please test with master and you should see that go away.
Yes, you are right.
Regardless, Marek's suggestion is the right fix if you can manage that... we really don't want to limit 4GB boards to 3GB. I was hoping NXP would step up and address the peripheral drivers for this.
Agreed, thanks!
But isn't the problem here that (some of) the hardware peripherals simply can't address memory above the 4GB boundary?
OS kernels can work around such limitations by using an IOMMU (if provided by the hardware) or by using bounce buffers (swiotlb in Linux speak).
Right, see bounce_buffer in U-Boot.
The traditional way to deal with this in u-boot is to make sure that u-boot only uses memory below the 4GB boundary by implementing board_get_usable_ram_top() and making sure that all the addresses in the u-boot environment are in "low" memory.
The board_get_usable_ram_top() purpose was something else entirely at the beginning, it only started being misused to work around driver issues instead of fixing them later and that is utterly wrong.
For EFI support there is the CONFIG_EFI_LOADER_BOUNCE_BUFFER option, which should be set to "y" in this case.
There is generic bounce buffer for drivers, see common/bouncebuf.c .