[haiku-gsoc] Re: Reserving space for kernel before loader leads to fault when turning on MMU

  • From: Arvind S Raj <sraj.arvind@xxxxxxxxx>
  • To: haiku-gsoc <haiku-gsoc@xxxxxxxxxxxxx>
  • Date: Wed, 6 Aug 2014 18:37:39 +0530

On 31 July 2014 17:37, pulkomandy <pulkomandy@xxxxxxxxxxxxx> wrote:
>
> If you add the gaps and things starts crashing, it means one of the
> sections is too small. This is an actual issue.
>
> With the gaps, you catch the issue immediately as the page boundary is
> crossed, you can analyse the fault (on Cortex-M you get the fault
> address in the BFAR register, I think Cortex-A is similar), and see
> which section needs to be resized.
>
> Without the gaps, the read or write will just touch the next section
> instead, without a fault. However, this will eventually lead to
> overwritten data, and a much harder to debug problem later on in the
> execution.
>
> In this case, I think it's better to take the time to step back and make
> sure we are mapping things in a sane way. Getting the kernel to boot by
> pure luck isn't a good long term solution. So yes, the gap is only to help
> debug things and is not a requirement of the hardware. But it can show
> important bugs in an easy to identify way.

Things have moved ahead till load_kernel now. Right now, there are two
issues I've noticed.

1. load_kernel faults when allocating space for the kernel by invoking
mmu_allocate. Seems like the values in few registers end up being
incorrect when 0x80008000 is mapped by map_page. I just realized the
issue could be because the registers get the wrong value when
restoring context before returning from map_page. I'll probably
investigate along those lines.

2. I noticed that quite a few traces display wrong
offset/address/values. For instance, this is the kernel stack bounds
as per the traces: "kernel stack at 0x80a100 to 0xb00000000080a140".
The bounds are stored in gKernelArgs and I found the right values when
investigating using gdb. I've also noticed that several other
numerical outputs in traces are also incorrect which suggest there's
some alignment/offset issue. I'm not entirely sure why but since
things are working fine otherwise, I suppose this issue is restricted
to trace outputs. Is there some kind of restriction on the alignment
of variables/values? I learnt that page tables have to be aligned at
16kB boundaries, which helped solved the fault as soon as MMU is
turned on when leaving a gaps between sections and just wondering if
someone is aware of some similar requirements.

Other related posts: