Hello,
Sorry to be lazy and not dig too deeply into the documentation and code, but
once upon a time it was possible to use the l4re_ma functions to allocate
pinned memory. Then, one would use the dataspace protocol to obtain the
physical address of the memory via the capability involved in memory
allocation.
This exercise would be sufficient to get into a position to initialise
peripherals in a system-on-a-chip, setting registers with the physical memory
addresses they would need for …
[View More]things like DMA. The initialisation of things
like framebuffers would rely on this procedure.
I see that the "phys" operation in the dataspace protocol was discarded some
time ago, and now there is a "DMA space" abstraction instead:
https://l4re.org/doc/group__api__l4re__c__dma.html
Are there any examples of how I might obtain a physical address associated
with a block of memory using this new API?
Thanks in advance for any guidance that might be offered!
Paul
[View Less]
Hello,
As part of reviewing my earlier efforts getting L4Re running on various MIPS-
based devices, I have been trying to get the bootstrap module to start the
kernel on the MIPS Creator CI20, and here I encounter a strange problem.
The bootstrap code appears to copy the different modules in the payload around
in memory, and for the kernel, it finds the different sections at 0x2f4000 in
physical memory (accessed via 0x802f4000), copying them into locations
relative to the indicated module …
[View More]base address (for example, 0x1100000 or
0x2000000). From their new locations, each section of the kernel is then
copied to its desired final address.
So, the section of the kernel providing its entry point can be found at
0x2f4000 + 0xa411c, this being copied to base + 0xa411c, before finally being
copied to 0x800d3000. However, the contents of memory at the final location
(0x800d3000) are not correct, nor are they at the "staging" location of base +
0xa411c, even though they do correspond to the expected contents of the kernel
binary at their original location.
What I expect to see at the entry point is...
40806000 mtc0 zero,c0_status
000000c0 ehb
What I see instead is...
ffffffff
bea3ffdf
Apart from at the original location in the payload (0x2f4000 + 0xa411c). As
far as I can tell, the second word is nonsense, and it is usually followed by
more ffffffff words. So, it is as if copying failed for this particular
section.
Oddly, this only seems to affect the section of the kernel providing the entry
point, and all other sections appear to be copied correctly from their
original locations. One factor might be that this section is the last one that
is copied.
Does this seem like recognisable behaviour of some kind of misconfiguration?
For the most part, I am just rebasing my old patches on the current L4Re and
Fiasco versions, so I didn't expect a problem at this level.
Regards,
Paul
[View Less]