Page MenuHomeFreeBSD

Use L2 blocks when in the identity map
AcceptedPublic

Authored by andrew on Dec 24 2020, 3:56 PM.

Details

Reviewers
manu
mmel
Group Reviewers
arm64
Summary

This reduces the memory mapped to be closer to the minimal memory
needed to enable the MMU.

Sponsored by: Innovate UK

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 35677
Build 32567: arc lint + arc unit

Event Timeline

I've tested the normal boot and with SOCDEV_PA set (but not used). I haven't tested any of the LINUX_BOOT_ABI paths.

Can you, please, rebase this to fresh tree?
Patch fails for me with:

git apply -p0  ../../git/D27765.diff
error: patch failed: sys/arm64/arm64/locore.S:497
error: sys/arm64/arm64/locore.S: patch does not app

Tested with LINUX_BOOT_ABI, everything works fine.
But why did you also change the behavior for SOCDEV_PA/VA? Removal of the option to choose a SOCDEV_PA looks a like step backward to me. This breaks existing code (but covered by #if 0) for example in uart_dev_snps.c. At least this change should be mentioned in commit message, but I think that old way is better.

I removed SOCDEV_VA because it's too difficult to know where the kernel will be loaded so we don't know a good virtual address at compile time.

The main reason fir the change is in perpetration for testing support for 16k pages where we don't have any L1 blocks, just L2 blocks and L3 pages. I also expect with a little work this will help with EARLY_PRINTF without having to modify driver to remove any #if 0s. The user could just change their config to point at the correct uart driver and set SOCDEV_PA to its base address.

This is not entirely true, for every SoC we know where DRAM is located and its maximum size. Same is true for all MMIO peripherals.

Also, having EARLY PRINTF without #if 0s depends on early platform interface support (which is almost impossible, i think) because uart PA (along with VA) is a platform property, not a uart driver property.

Anyway, it's a small enough problem (for me) that shouldn't block any further work.

This revision is now accepted and ready to land.Dec 27 2020, 3:58 PM