On Fri, Jun 5, 2020 at 6:19 PM 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. > > I agree, sorry, after looking around a bit more I realized some of the above limitations. > 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. No this will not be an issue, we can set the bits[1:0] of the table-entry to account for the levels of page tables. I was thinking about ways to simplify the implementation of stack allocation, but doing this is definitely not feasible. > 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. > > Is the above-suggested implementation feasible? > > > > Regards, > > Utkarsh > > > > -- > Hesham >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
