12 Jun
2020
12 Jun
'20
3:42 p.m.
Hi Ben,
Sorry, it took so long to get back to you, I was quite busy and I had to do a little
research for your questions.
I'm not confident I'm correct in some of these answers as I mostly work above
the kernel.
Q: Why are there two separate memory regions defined here?
*and*
Q: Out of the available memory region (0x40000000 - 0xbea00000), what can I use
and what constrains the kernel load address within this available memory?
A: The 'memory' block is used for normal applications and the
'vm-memory' block
is memory used exclusively for the VMs. As I recall, the VM memory region is as
it is due to some limitations of Linux or perhaps the memory controller of the
platform in regards to memory interactions with the platform peripherals. I'm
not too sure on this, and perhaps someone else more familiar with the VMs can
chime in.
Q: The comment that states that this file contains a hack to get around an ASID
memory hole, however I don't understand how that hole can exist on this
platform, as the memory is supposed to be contiguous from 0x40000000 to
0xbea00000?
A: The hole is mostly a kernel implementation issue. The kernel window for the
kernel ELF and addressable memory is 0xe0000000 to 0xff000000. Addresses after
this is reserved for other things, hardware ASIDs, devices, vectors, etc. Also
it just so happens that the overlay contains a typo, the ASID memory hole is
actually starts at 0xff000000.
Q: Why is the bulk of the memory provided by the device missing from this file?
*and*
Q: I also don't understand how the addresses stated in the comment have
anything to do with the XU4's memory region, as the addresses referenced are
far higher than the 0xbea00000 address at the end of the XU4's memory region?
A: Due to memory limitations of the kernel.
The whole memory region is given to the kernel and is mapped at a specific
address. The kernel is mapped at 0xe0000000 on Exynos5422 (odroid-xu4)
platforms. There's a difference of 0x1f000000 bytes between that and the top
of the largest contiguous region in the kernel window.
The kernel only creates normal untyped memory from physical memory that it can
access virtually hence the need to clamp the memory region. I'm not too sure if
this is exactly the case, and hopefully someone with more knowledge about the
kernel can expand on this more.
Q: How is the kernel load address determined? From my investigations it seems
this is simply the first memory region defined in the overlay file (which may
explain why there are multiple) however when I attempt to change that region to
anything other than 0x60000000 it doesn't seem to work.
I have added the missing memory regions manually, and have had varying success
in using different memory regions. For example, I have been able to declare
memory from 0x80000000 and up, and specify that as the VM_RAM_BASE which works
Regards,
Damon