[PATCH] openfirmware: Skip mappings to non-physical memory

[andreasf]

INIT: init VM semaphores
PANIC: looking up page failed for pa 0x80800000

OpenBIOS sets up these identity mappings:

80800000 (0x   80000) -> 80800000
80881000 (0x    1000) -> 80881000
80a00000 (0x   10000) -> 80a00000
90000000 (0x10000000) -> 90000000
fe000000 (0x   10000) -> fe000000
fec00000 (0x    1000) -> fec00000
fee00000 (0x    1000) -> fee00000

The problem is that they are all outside of (here 512 MB) RAM area, so we won't get a vm_page* but the above panic from vm_create_anonymous_area later in the kernel.

Don't add those ranges as to-keep, based on is_physical_memory.

An alternative might be to skip them based on the mode supplied by OpenBIOS but I'm not familiar with its semantics yet.

Not sure if this is the right way to fix. It does get us further a little.

[andreasf]

proposed patch

[stippi]

Applied in hrev34863. I'll leave the ticket open, since I don't really have a clue if the proposed fix needs more work or not. It made sense to me to apply it as is, since as you say, it gets the PPC kernel booting a little further... :-)

[bonefish]

I haven't looked into the code any further, but IIRC the "ranges to keep" have the sole purpose to allow OF calls when already in the kernel. I believe the whole concept -- or at least its current implementation -- is seriously flawed. The kernel address space starts at 2 GB, that is any mappings below that point cannot be preserved this way. Since OF usually identity maps the memory it uses, that means OF allocated memory will most likely not survive. ATM arch_vm_init_end() only creates memory-backed areas (which is the problem you're apparently running into), which means that mappings for memory mapped I/O can't be used either.

So essentially the whole mechanism is useless ATM (which might also explain why I had problems with reset or shutdown via OF once the kernel had taken over). I would rather revert the patch and comment out the code adding the OF mappings to the "ranges to keep" for the time being. Until the mechanism is replaced/fixed that is.

[andreasf]

patch: revert hrev34863 and don't add ranges to keep

[andreasf]

With the attached patch I get to

INIT: init VM semaphores

where it just hangs.

[andreasf]

workaround: just free kernel ranges

[andreasf]

By freeing only part of the ranges, I get to

INIT: init kernel daemons

Specifically, in KernelDaemon::Init (ppc/kernel_daemon.cpp) spawn_kernel_thread does not return.

[andreasf]

More specifically, spawn_kernel_thread (thread.cpp) calls create_thread and in turn arch_thread_init_kthread_stack, where the memset of 0x80a01000 (size 0x3000) does not return.

As can be seen above, 0x80a0000 is identity-mapped in OpenFirmware.

[bonefish]

Reverted the first patch and uncommented the addition of virtual ranges in hrev36886. Basically what the second patch does, just with a comment and without a warning.

I don't see a convincing reason for attachment:ppc_free_unused_boot_loader_range2.diff​ ATM.

Replying to andreasf:

More specifically, spawn_kernel_thread (thread.cpp) calls create_thread and in turn arch_thread_init_kthread_stack, where the memset of 0x80a01000 (size 0x3000) does not return.

As can be seen above, 0x80a0000 is identity-mapped in OpenFirmware.

It shouldn't be mapped at this point anymore.

[andreasf]

Thanks.

Replying to bonefish:

I don't see a convincing reason for attachment:ppc_free_unused_boot_loader_range2.diff​ ATM.

As a workaround, it was not intended to be applied to SVN. But it gets us further into the kernel. I believe you suggested this may be due to OpenFirmware <2GB memory getting unmapped, while still trying to use OF for dprintf etc. I'll open a new ticket to track the current breakage.

[andreasf]

hrev36886 was too strict apparently: OpenFirmware itself is unmapped that way.

[andreasf]

proposed patch: explicitly keep the translation containing OpenFirmware

[andreasf]

proposed patch: revert hrev36886 and update insert_virtual_range_to_keep

[andreasf]

proposed patch: distinguish between RAM and non-RAM ranges to keep

[andreasf]

draft patch: pretend to set any memory type

[andreasf]

Ha! I've found a way to create areas for the non-RAM ranges, too!

As heuristic I'm using the available memory size.

For the non-RAM areas a memory type of 0x10000000 is getting set, which is not supported yet. I'm just ignoring it for now.

[bonefish]

Replying to andreasf:

Ha! I've found a way to create areas for the non-RAM ranges, too!

As heuristic I'm using the available memory size.

That only works, when the physical memory is contiguous. The kernel args contain the actual physical memory ranges.

For the non-RAM areas a memory type of 0x10000000 is getting set, which is not supported yet. I'm just ignoring it for now.

The PPC arch_vm_set_memory_type() can be implemented to just return B_OK (I believe there is no such mechanism as MTRRs for PPC) as soon as memory types are supported at the paging level (TODO's in PPCVMTranslationMap::Map() and friends; cf. the specs: "Storage Control Attributes" / WIMG bits).

Note that you should retrieve the actual memory type from the mapped ranges and pass it to vm_map_physical_memory().

[andreasf]

Replying to bonefish:

Replying to andreasf:

As heuristic I'm using the available memory size.

That only works, when the physical memory is contiguous. The kernel args contain the actual physical memory ranges.

My heuristic was bogus in that the available memory is actually lower than the OpenFirmware start.
Testing with a hardcoded value, it turns out that create_area() still does not work here. So we can drop that part.

Note that you should retrieve the actual memory type from the mapped ranges and pass it to vm_map_physical_memory().

Unfortunately I fail to see how.

[andreasf]

proposed patch: revert hrev36886 and update insert_virtual_range_to_keep

[andreasf]

proposed patch: map physical memory to keep differently

[andreasf]

I've rebased and updated patch 1 to remove the TODO as well which will be obsoleted by patch 2. Patch 2 was updated as described above.

[andreasf]

Applied both patches in hrev38291.