l4-hackers

Download

l4-hackers@os.inf.tu-dresden.de

April 2023

2 participants
2 discussions

L4Re: Allocating pinned memory and obtaining its physical address
by Paul Boddie 24 May '23

24 May '23

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 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

3 5

L4Re: Boot module copying and the MIPS Creator CI20
by Paul Boddie 21 May '23

21 May '23

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 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

3 12