Conversation
Conor Dooley
conor
re: https://social.kernel.org/notice/AS3DZjXqKnHXtM8ZEG
Problem 1:
Nick fixed about a year ago, and to quote his commit message
```
In case the DTB provided by the bootloader/BootROM is before the kernel
image or outside /memory, we won't be able to access it through the
linear mapping, and get a segfault on setup_arch(). Currently OpenSBI
relocates DTB but that's not always the case (e.g. if FW_JUMP_FDT_ADDR
is not specified), and it's also not the most portable approach since
the default FW_JUMP_FDT_ADDR of the generic platform relocates the DTB
at a specific offset that may not be available. To avoid this situation
copy DTB so that it's visible through the linear mapping.
```
Problem 2:
I fixed a few months ago. The reserved memory scanning takes place too early
during init, before paging has been enabled. As a result, once paging *is*
enabled & the tlb flushed, trying to read the label names of reserved memory
regions causes a kernel panic. Apparently we were just the first ones to try
to write a remoteproc driver for RISC-V!
The solution was moving the call to early_init_fdt_scan_reserved_mem() after
the dtb was properly mapped.
Problem 3:
If the dtb is located outside of memory regions that the kernel is aware of, it
gets remapped into a region that the kernel *is* aware of.
However, this is done before we check for any reserved memories etc. If there
happened to be a section of unusable memory in the DT, that was then carved
out using a reserved memory region with a "no-map" property, it is entirely
possible that the DT would end up there.
This was introduced by Nick's fix for problem 1 & I've been avoiding it by just
putting the dtb somewhere that I know will be accessible to the kernel, and thus
avoiding the remapping.
Problem 4:
Introduced by my fix for problem 2. RISC-V uses the top-down method for looking
up memblocks for reserved memory regions. In a sparse configuration, if there
was to be an upper-most range, all of which was intended to be used as a DMA
region, memory allocated at some point in paging_init() would consume very small
sections of this upper DMA region. This can be observed on some configurations
on PolarFire SoC, and was easy to spot with memblock debug enabled.
These small allocations mean that when, in early_init_fdt_scan_reserved_mem(),
we look up the reserved memory node that is intended to consume the whole memory
region there is no longer enough space for this mapping.
This is worse if the memory region is non-coherent as the system will then
immediately crash.
Problem 4 can be fixed by using bottom-up searching for memblocks. This may also
fix problem 3 too, I just haven't tested it.
I'm super unsure as to whether switching the search order has some consequences
that I am just not aware of, but I probably won't be any the wiser until I send
a patch!
Problem 1:
Nick fixed about a year ago, and to quote his commit message
```
In case the DTB provided by the bootloader/BootROM is before the kernel
image or outside /memory, we won't be able to access it through the
linear mapping, and get a segfault on setup_arch(). Currently OpenSBI
relocates DTB but that's not always the case (e.g. if FW_JUMP_FDT_ADDR
is not specified), and it's also not the most portable approach since
the default FW_JUMP_FDT_ADDR of the generic platform relocates the DTB
at a specific offset that may not be available. To avoid this situation
copy DTB so that it's visible through the linear mapping.
```
Problem 2:
I fixed a few months ago. The reserved memory scanning takes place too early
during init, before paging has been enabled. As a result, once paging *is*
enabled & the tlb flushed, trying to read the label names of reserved memory
regions causes a kernel panic. Apparently we were just the first ones to try
to write a remoteproc driver for RISC-V!
The solution was moving the call to early_init_fdt_scan_reserved_mem() after
the dtb was properly mapped.
Problem 3:
If the dtb is located outside of memory regions that the kernel is aware of, it
gets remapped into a region that the kernel *is* aware of.
However, this is done before we check for any reserved memories etc. If there
happened to be a section of unusable memory in the DT, that was then carved
out using a reserved memory region with a "no-map" property, it is entirely
possible that the DT would end up there.
This was introduced by Nick's fix for problem 1 & I've been avoiding it by just
putting the dtb somewhere that I know will be accessible to the kernel, and thus
avoiding the remapping.
Problem 4:
Introduced by my fix for problem 2. RISC-V uses the top-down method for looking
up memblocks for reserved memory regions. In a sparse configuration, if there
was to be an upper-most range, all of which was intended to be used as a DMA
region, memory allocated at some point in paging_init() would consume very small
sections of this upper DMA region. This can be observed on some configurations
on PolarFire SoC, and was easy to spot with memblock debug enabled.
These small allocations mean that when, in early_init_fdt_scan_reserved_mem(),
we look up the reserved memory node that is intended to consume the whole memory
region there is no longer enough space for this mapping.
This is worse if the memory region is non-coherent as the system will then
immediately crash.
Problem 4 can be fixed by using bottom-up searching for memblocks. This may also
fix problem 3 too, I just haven't tested it.
I'm super unsure as to whether switching the search order has some consequences
that I am just not aware of, but I probably won't be any the wiser until I send
a patch!
0
0
0