alternative armv6 PMAP strictly derived from i386 pmap

[Olivier Houchard]

On Tue, Dec 17, 2013 at 02:13:56PM +0100, Svatopluk Kraus wrote:
> Hi, arm community!
> 

Hi Swatopluk,

I see you got no answer yet.
I just wanted to let you know that we are interested in your work, and are
currently investigating importing parts of it (recursive page tables instead
of the crappy stuff we currently have immediately comes to mind).

Thanks a lot for sharing !

Regards,

Olivier
 
> About two years ago, when I and Michal Melound have started porting FreeBSD
> on newly developed board, we had to make decision which was not too easy.
> The new board was based on arm11 mpcore and there was not real SMP support
> for arm in FreeBSD source tree. We grew up on i386 architecture. This arch
> is quite familiar for us. When we was porting FreeBSD on Coldfire, we was
> using i386 tree as starting point. So, we had to choose: First, to start to
> port arm11 mpcore using i386 tree or second, try to learn existing arm tree
> and change it to support SMP. The decision was not so easy. However, we had
> no coding experience with SMP till then and i386 arch was familiar and
> already SMP. Current arm port looked influenced too many by prior arm
> platforms. Futher, we already had made a successful port on Coldfire this
> way.
> 
> Unfortunatelly, due to other work, we could not present our armv6 pmap
> implementation until now. So now, when one pmap-v6.c is in FreeBSD tree
> already, this is, at least, inteded for everybody who could be interested
> in.
> 
> Now, some words about our implementation.
> 
> (1) PIPT data cache was taken as prerequisite. This way the code is not
> influenced by VIVT data cache impact.
> 
> (2) The code is SMP and L2 cache compliant. Fully tested on arm11 mpcore
> platform.
> 
> (3) We do not use domains. Instead, global and not global mappings are
> implemented.
> 
> (4) As we had experience with port for Colfire, where page table entries
> are two 32 bit words, and because it has many good implications, we
> strictly are using dedicated functions for manipulation with page tables
> entries. For example, this way we easily can seek for every mapping made in
> so large pmap.c file.
> 
> (5) We use similar aproach for L2 page tables as in i386 arch. So each
> process has mapped all its L2 page tables in dedicated address space. The
> address space is shared by all processes. The cost is only one page per a
> process, but this page keeps track of all L2 page tables in a process
> simultaneously.
> 
> (6) Section mapping is implemented. Super section not, but it could be
> easily coded too.
> 
> (7) We joined data and prefetch aborts into one routine.
> 
> (8) We are using inlines instead of macros because of type checking.
> 
> (9) The code is fully commented. Mainly arm specific parts. Plus, our
> internal comments are leaved in code too.
> 
> (10) We still keep track of i386 implementation. For large parts, which are
> almost same, we extended testing community a lot.
> 
> Our work is in progress, so some files are not cleaned yet. Our
> implementation as it is not prepared for compilation in FreeBSD source
> tree. We plan to try to make it alive for pandaboard we already have got.
> Unfortunatelly, we have not too much time we can spend on it right now.
> However, if somebody would like to take a try, we can support him/her with
> everything needed.
> Some more files are provided for better insight to our port.
> 
> https://drive.google.com/folderview?id=0Bx9OFLzdl65mNVRiQUs1UXhPZmc&usp=sharing
> 
> 
> Svatopluk Kraus
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"