Hi Bob,
The core tlb I created defines a RAM region that cover the entire RAM available on the board, which covers the .text and .bss sections. Also includes two MMIO regions that cover controls for devices and the devices themselves.
Setting the C and the I bits the System Control register to zero had no effect.
I'll dig deeper into the CPU behavior and see what I can find.
without looking specifically at Cortex-A8, I have two ideas of what could go wrong:
First, the only Cortex-A8-based platform supported by base-hw so far is i.MX53. In contrast to most low-cost ARM-platforms, i.MX53 starts the kernel in secure mode. Maybe your platform starts the kernel in non-secure mode? If I remember right, the secure/non-secure mode must be distinguished when setting up mappings in the page table.
Second, may it be that enabling the MMU actually succeeds but the UART device is not mapped correctly? As soon as the MMU gets activated, all I/O accesses go through the MMU as well. You could try out the following experiment:
1. Enable the MMU (via the existing call of 'init_virt_kernel' in kernel.cc) 2. Immediately disable the MMU again (add a call to 'init_phys_kernel' directly after the 'init_virt_kernel' call. 3. Print a message. 4. Enable the MMU again.
If you see the message, you know that at least the code for disabling the MMU was successfully executed while the MMU was active. This would indicate that not the MMU but the mapping of your UART is the problem.
Cheers Norman