Opened 5 years ago

Closed 5 years ago

#10984 closed bug (fixed)

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

Reported by: arvindsraj Owned by: ithamar
Priority: normal Milestone: R1
Component: System/Boot Loader Version: R1/Development
Keywords: gsoc2014 Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: arm


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.

Attachments (3)

Change History (13)

comment:1 by arvindsraj, 5 years ago

Has a Patch: set

comment:2 by anevilyak, 5 years ago

Component: - GeneralSystem/Boot Loader
Owner: changed from nobody to ithamar
Platform: Allarm
Status: newassigned

comment:3 by pdziepak, 5 years ago

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

comment:4 by pulkomandy, 5 years ago

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.

comment:5 by arvindsraj, 5 years ago

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

comment:6 by pulkomandy, 5 years ago

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.

comment:7 by arvindsraj, 5 years ago

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( but the stack frames for start_netbsd and start_raw are using up physical memory. Would that be a problem?

comment:8 by ithamar, 5 years ago

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.

comment:9 by ithamar, 5 years ago

committed as part of hrev47436

comment:10 by ithamar, 5 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.