Bug: PHYS_OFFSET no longer points to DRAM physical starting address with CONFIG_ARM64_VA_BITS_52

Chen-Yu Tsai <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,dev.linux.lists.linux-sunxi
Message-ID <CAGb2v640LRCYpRq8omyRirD4CUSd2mjm72EJ9FtWvZe=Vovg1A@mail.gmail.com>
Hi,

On the Allwinner H6 & H616 SoC (and likely others), if running a kernel
compiled with CONFIG_ARM64_VA_BITS_52 and CONFIG_ARM64_PA_BITS_52,
PHYS_OFFSET no longer points to the start of DRAM (0x40000000) but instead
points to 0xfff1000040000000.


I've observed this for quite some time but hadn't really nailed down what
was going on. For context: the IOMMU on these SoCs can only do 32-bit
addresses, and that's pretty fine since the SoC only supports up to 4 GB
DRAM. However the DRAM starts at 1GB offset in the physical address space.
We want to be able to map the highest 1GB I/O virtual address space and
thus need to check if the physical address is within 4GB without the
offset. Having only 32-bits addressing, the address will wrap around fine.
So we check the address against PHYS_OFFSE, which breaks with the mangled
address.


I suspect this is the result of the following commits:

    7bc1a0f9e176 arm64: mm: use single quantity to represent the PA to
VA translation
    9684ec186f8f arm64: Enable LPA2 at boot if supported by the system

The first commit introduces a negative (wrapped around) offset to
memstart_addr (PHYS_OFFSET) to work around mapping restrictions, and the
second commit makes the offset dependent on hardware.


I hope that Ard and the maintainers can look into it and make PHYS_OFFSET
always point to the physical start of DRAM.


Thanks
ChenYu
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.