On 2/25/22 12:37, Mark Kettenis wrote:
From: Fabio Estevam <feste...@gmail.com>
Date: Fri, 25 Feb 2022 08:12:58 -0300
Hi Tim,
On Thu, Feb 24, 2022 at 6:46 PM Tim Harvey <thar...@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 .
