Fault raised due to invalid memory access when MMU is turned on

[arvindsraj]

As soon as MMU is enabled, the pre-MMU stack becomes invalid because a valid mapping doesn't exist. This has been fixed by moving the stack to the an address specified in LOADER_MEMORYMAP array such that the stack remains valid even after MMU is enabled.

[pdziepak]

What is the point of using r2 instead of directly accessing sp?

Also, what about something like:

#define STACK_BASE (SDRAM_BASE + 0x1200000)
...
ldr sp, =STACK_BASE

[pulkomandy]

Yes, pdziepak suggestion would be much better, there is no point in doing the math at runtime when the C preprocessor can do it for us. I think even

ldr sp,=SDRAM_BASE + 0x1200000

should work? But if it doesn't, a define is ok.

[arvindsraj]

I tested pulkomandy's suggestion and it works fine. I've attached a revised patch.

[pulkomandy]

I think there is another problem. Like on most systems, the stack grows downward (towards lower addresses), so the initial pointer must be set to the end of the stack area, rather than the beginning. Otherwise, you risk overwriting things below SDRAM_BASE+0x1200000.

[arvindsraj]

In the newest version of the patch, sp points to the highest address of the RAM_stack specified in LOADER_MEMORYMAP.

Also, mmu_init sets the amount of physical memory allocated to 0(​http://cgit.haiku-os.org/haiku/tree/src/system/boot/arch/arm/arch_mmu.cpp#n621) but the stack frames for start_netbsd and start_raw are using up physical memory. Would that be a problem?

[ithamar]

no, those values are for the kernel to use, and since the kernel takes over the machine, with no way of returning to the loader or U-Boot, this is fine. All the loader's memory will be reused by the kernel anyway.

[ithamar]

committed as part of hrev47436