Am 27. Mai 2024 17:49:26 UTC schrieb Bernhard Beschow <shen...@gmail.com>:
>
>
>Am 27. Mai 2024 16:20:44 UTC schrieb Richard Henderson
><richard.hender...@linaro.org>:
>>On 5/27/24 08:29, Bernhard Beschow wrote:
>>> I think the kernel's output indicates that the MMU is active:
>>>
>>> [7e849b05] *pgd=2c552831, *pte=109eb34f, *ppte=109eb83f
>>>
>>> AFAIU, the value in brackets is a virtual address while the pte's are
>>> physical ones. Furthermore, the `info mtree` QMP command tells that the
>>> physical addresses are RAM addresses:
>>>
>>> 0000000010000000-000000002fffffff (prio 0, ram): sabrelite.ram
>>>
>>> So I think we can conclude this to be "normal memory" to speak in ARM terms.
>>
>>Normal and Device are attributes on the page table entry.
>>See section G5.7 Memory region attributes in the Arm ARM.
>>
>>But it's unlikely that the Linux kernel has messed this up, even back in 4.x
>>days.
>>
>>If you want to make any progress, you'll have to share a test case.
>
>It's a proprietary guest, so I need to strip it down first. This may take some
>time. Thanks for yor feedbak so far!
I finally had some time to look deeper into it. While this patch triggered
alignment issues, it is not the culprit. The culprit is that the sabrelite
board sets arm_boot_info::secure_boot = true which causes the Linux kernel to
run in EL3 mode where hardware alignment fixing is apparently not performed.
Setting it to false fixes all problems and the guest boots just fine.
Question: Does it make sense to ignore the secure_boot flag on direct kernel
boot? If not, what do you suggest?
Thanks,
Bernhard
>
>Best regards,
>Bernhard
>>
>>
>>r~
