base-hw ,,, What is CACHE_LINE_SIZE_LOG2?

[Norman Feske]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth