Hi, I'm currently experiencing a bug during the port of the kernel on a new architecture and after looking at other architectures, I suspect the problem might be there too. my question is about reserved memories and usage of early device tree. >From what I understand, when reserved memory is initialized using early_init_fdt_scan_reserved_mem, the reserved memories are created using some pointers inside the early dt (mainly the names). If this early device tree is located into the init section (when using a builtin dtb for instance), this section will be discarded (when calling free_initmem_default) and memset with a zero/poison value. So all pointers which are referencing the early dt will be invalid. This will clobber all the "names" of the reserved memory entries. As a side effect, all drivers using of_reserved_mem_lookup after the init section has been freed will always failed because the search is based on the name of the reserved mem. I also said that it might be present on other architectures because the usual function call I found is the following: - early_init_dt_scan - early_init_fdt_reserve_self (only reserve memory in memblock) - early_init_fdt_scan_reserved_mem - unflatten_and_copy_device_tree - free_initmem_default - potential calls to of_reserved_mem_lookup Which (if the device tree is builtin in init section) will lead to the result I described before. So my question is about the legit usage of pointers referencing the early dtb. If is it ok to use such pointers, this means that the early dtb must always be available and that when using a builtin dtb, then it should probably be copied early before using it for scan operations with unflatten_and_copy_device_tree. However, since the scan of the reserved mem nodes is required to avoid allocating in reserved memory, unflatten_and_copy_device_tree should probably not be called before early_init_fdt_scan_reserved_mem since it allocates data. So this is a bit of the snake biting its tail and thus, early dt pointers should probably not be used. Is my understanding correct ? Or have I missed something since it seems to haven't been noticed on other architectures ? Thanks & regards, Clément
