[PATCH 4/6] imx8m: Restrict usable memory to space below 4G boundary
Marek Vasut
marex at denx.de
Tue Jul 13 12:31:02 CEST 2021
On 7/13/21 11:25 AM, Frieder Schrempf wrote:
> On 15.06.21 02:41, Marek Vasut wrote:
>> On 6/15/21 2:28 AM, Peng Fan (OSS) wrote:
>>>
>>>
>>> On 2021/6/7 20:38, Marek Vasut wrote:
>>>> On 6/7/21 2:05 PM, Frieder Schrempf wrote:
>>>>> From: Frieder Schrempf <frieder.schrempf at kontron.de>
>>>>>
>>>>> Some IPs have their accessible address space restricted by the
>>>>> interconnect. Let's make sure U-Boot only ever uses the space below
>>>>> the 4G address boundary (which is 3GiB big), even when the effective
>>>>> available memory is bigger.
>>>>>
>>>>> We implement board_get_usable_ram_top() for all i.MX8M SoCs, as the
>>>>> whole family is affected by this.
>>>>
>>>> Shouldn't only those specific IP drivers handle buffers in the 64bit space somehow ? E.g. using a bounce buffer ?
>>>
>>> That could cause extra mem copy.
>>
>> If you want to avoid the extra memcopy, then make sure the buffers are not allocated above 4 GiB boundary. Then the bounce buffer does no copy.
>>
>> This board_get_usable_ram_top() is just a temporary workaround for platforms with broken drivers which are not fixed yet, so please fix the drivers instead.
>>
>>> Bounce buffer would be good for systems
>>> that take U-Boot as UEFI firmware, because U-Boot would be located at
>>> high end, but in the middle just top of 4GB.
>>
>> The bounce buffer is a necessity for IPs which cannot address more than the 4 GiB of memory. In fact, it would be even better to handle DT dma-ranges, but that is the next step.
>>
>>> I not object this patch, but it also be good if bounce buffer be added
>>> for improvement.
>>>
>>> Reviewed-by: Peng Fan <peng.fan at nxp.com>
>>
>> I do object to this, since it increases the proliferation of this broken board_get_usable_ram_top() workaround instead of fixing the drivers properly.
>
> I generally agree with Marek's objections and if anyone comes up with a proper fix this will be highly appreciated. For now I just dropped this patch from my v2 patchset, but Stefano has already pulled it into u-boot-imx. I guess it's up to him to decide if this intermediate fix should be merged or not.
Fix the drivers, that is the only way unless you want to see U-Boot turn
into pile of hacks and workarounds which become unmanageable.
More information about the U-Boot
mailing list