IMX8MM 4GiB boundary issue

Marek Vasut marex at
Fri Feb 25 14:50:59 CET 2022

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

More information about the U-Boot mailing list