forked from luck/tmp_suning_uos_patched
fded332bf4
With the kernel loaded to FastRAM (TT-RAM), none of the ST-RAM address range is mapped by init_mem, and ST-RAM is not accessible through the normal allocation pathways as a result. Implement ST-RAM pool allocation to be based on physical addresses always (it already was when the kernel was loaded in ST-RAM). Return kernel virtual addresses as per normal. The current test for the kernel residing in ST-RAM always returns true. Use the bootinfo memory chunk order instead - with the kernel in FastRAM, ST-RAM (phys. 0x0) is not the first chunk. In case the kernel is running from FastRAM, delay mapping of ST-RAM pool until after mem_init. Provide helper functions for those users of ST-RAM that need to be aware of the backing physical addresses. Kudos to Geert for his hints on getting this started. Signed-off-by: Michael Schmitz <schmitz@debian.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> |
||
---|---|---|
.. | ||
asm | ||
uapi/asm |