Messages in this thread | | | From | Arnd Bergmann <> | Date | Tue, 14 Apr 2020 21:29:46 +0200 | Subject | Re: [PATCH 0/3] Highmem support for 32-bit RISC-V |
| |
On Tue, Apr 14, 2020 at 5:17 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote: > > + rmk > > Hi Arnd, > > On Wed, Apr 08, 2020 at 04:40:17PM +0200, Arnd Bergmann wrote: > > > No code yet, so far not much more than the ideas that I listed. We > > are currently looking for someone interested in doing the work > > or maybe sponsoring it if they have a strong interest. > > If no one have yet taken it up, i am interested in doing the work, i > will sponsor myself :). i will proceed at a slow pace without derailing > my other things normal. > > To keep expectations realistic: i have not yet taken task of this > complexity, it is more of a learning for me. My familiarity with Linux > at the ARM architecture level is mostly on no-MMU (Cortex-M), have not > worked so far seriously on MMU Linux at the ARM architectural level, > though used to go through ARM ARM v7-AR at times.
Thanks for offering to help, it's very much appreciated. Let me know how it goes and if you have any more detailed questions.
> i have a few 32-bit ARM Cortex-A (A5, A8 & A9) boards, maximum RAM 1G, > none have LPAE, seems i have to buy one for this purpose.
I would recommend starting in a qemu emulated system on a PC host, you can just set it to emulate a Cortex-A15 or A7, and you can attach gdb to the qemu instance to see where it crashes (which it inevitably will).
You can also start by changing the functions in asm/uaccess.h to use the linear kernel mapping and memcpy(), like the version in arch/um/kernel/skas/uaccess.c does. This is slow, but will work on regardless of whether user space is mapped, and you can do a generic implementation that works on any architecture and put that into include/asm-generic/uaccess.h.
A second step after that could be to unmap user space when entering the kernel, without any change in the memory layout, this is still mostly hardware independent and could easily be done in qemu or any 32-bit ARM CPU.
Another thing to try early is to move the vmlinux virtual address from the linear mapping into vmalloc space. This does not require LPAE either, but it only works on relatively modern platforms that don't have conflicting fixed mappings there.
If you get that far, I'll happily buy you a Raspberry Pi 4 with 4GB for further experiments ;-) That one can run both 64-bit and 32-bit kernels (with LPAE), so you'd be able to test the limits and not rely on qemu to find all bugs such as missing TLB flushes or barriers.
Arnd
| |