On Fri, Jun 5, 2020 at 6:49 AM Hesham Almatary <heshamelmat...@gmail.com> wrote: > > Hello Utkarsh, > > TTBR1 is there primarily for UNIX-like kernels to be re-mapped at very > high addresses and user space can use TTBR0. In the case of RTEMS, we > don't have that user vs kernel separation. Furthermore, using TTBR1 > won't allow us to do 1:1 fixed mappings. > > Could you give more details why having different page sizes would be > an issue? You would normally have multi-level page tables for more > fine-grained page sizes. +1
> > On Thu, 4 Jun 2020 at 11:44, Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > > > Hello, > > > > Section B3.3.3 of the ARMv7-A Reference manual says that we can have TTBR0 > > and 1 split up the address space into two parts, where each register has > > the address of the translation table base > > of the divided address space. > > One of the ways to simplify the implementation of thread-stack protection > > in ARMv7-A MMU can be, to have the global statically allocated sections > > being pointed by the TTBR1 register and the work-space area being pointed > > out by the TTBR0 register. This way during context switch we would only > > have to change the TTBR0 register, this would also simplify the > > implementation as we won't have to worry about addresses of different page > > sizes being pointed by the same translation-table base. > > In the current implementation, TTB is put in TTBR0, and TTBR1 is not used. To clear a possible confusion, you can't have multiple workspaces. That is the dynamic memory region (e.g., program heap) used by RTEMS to manage object allocations. > > Is the above-suggested implementation feasible? > > > > Regards, > > Utkarsh > > > > -- > Hesham > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
