On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE alexandre.torgue@foss.st.com wrote:
On 4/20/21 4:45 PM, Rob Herring wrote:
On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE alexandre.torgue@foss.st.com wrote:
Hi,
Greg or Sasha won't know what to do with this. Not sure who follows the stable list either. Quentin sent the patch, but is not the author. Given the patch in question is about consistency between EFI memory map boot and DT memory map boot, copying EFI knowledgeable folks would help (Ard B for starters).
Ok thanks for the tips. I add Ard in the loop.
Sigh. If it was only Ard I was suggesting I would have done that myself. Now everyone on the patch in question and relevant lists are Cc'ed.
Ard, let me know if other people have to be directly added or if I have to resend to another mailing list.
thanks alex
Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map" reserved-memory regions are no more "reserved" and make part of the kernel System RAM. This causes allocation failure for devices which try to take a reserved-memory region.
It has been introduced by the following path:
"fdt: Properly handle "no-map" field in the memory region [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]" which replace memblock_remove by memblock_mark_nomap in no-map case.
Reverting this patch it's fine.
I add part of my DT (something is maybe wrong inside):
memory@c0000000 { reg = <0xc0000000 0x20000000>; };
reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges;
gpu_reserved: gpu@d4000000 { reg = <0xd4000000 0x4000000>; no-map; };};
Sorry if this issue has already been raised and discussed.
Thanks alex