Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(un-)used memory regions for shared memory on SoC #253

Open
Vincer239 opened this issue Dec 5, 2024 · 4 comments
Open

(un-)used memory regions for shared memory on SoC #253

Vincer239 opened this issue Dec 5, 2024 · 4 comments

Comments

@Vincer239
Copy link

Hi,
I am currently working on implementing a proof-of-concept demonstrator on a Xilinx Zynp Ultrascale+
The demonstrator is using a softcore DMA to efficiently load data from the Processing System running seL4/microkit to the Programmable Logic and vice versa.

Long story short:
In microkit, I need to define the memory region where the DMA can read data from and write data to. For this, I have looked through your documentation and the build reports to try and see what memory locations you block for your software and where I can map my stuff to. I couldn't find anything concrete.

I've been guesstimating a bit but I am not that happy with it.
Have I missed this information somewhere? I would like to not map DMA onto your kernel or other code by accident...

@Ivan-Velickovic
Copy link
Collaborator

Ivan-Velickovic commented Dec 6, 2024

There's reserved regions for kernel memory, the monitor and the PD program images. Some of this information is displayed at the top of the report, e.g for hello world it looks like this:

# Loader Regions

       <Region name=PD-ELF hello-0 addr=0x60247000 size=1045>
       <Region name=PD-ELF hello-1 addr=0x60248000 size=104>

# Monitor (Initial Task) Info

     virtual memory : MemoryRegion(base=0x8a000000, end=0x8a008000)
     physical memory: MemoryRegion(base=0x60249000, end=0x60251000)

although this is missing the kernel region and isn't that clear, 'Reserved Regions' would be better.

I believe the tool reports an error if you try to create a mapping within one of these reserved regions, I've never tried to do it myself so I will double check. If there is no error reported then it is a bug.

@Ivan-Velickovic
Copy link
Collaborator

Trying it out now, I can find a couple of cases where it either leads to an assertion or produces an image when it shouldn't have. I will fix that and improve the error messages.

Thanks for reporting the issue.

@Vincer239
Copy link
Author

Ah thank you for the answer and nice to be of help :)

My thought behind this question was a little different..
I imagined that you might have some static mapping like

addr 0x0000 to 0x1FFF => kernel code
addr 0x2000 to 0x3FFF => PDs
addr 0x4000 to 0x5FFF => ...

But at least in your example it seems that this is not the case as this address is somewhere in the middle of the address space (middle of it might also be an overstatement as it starts at 0x60247000 and the increments -- but why exactly there..)?

Do you have a rule of thumb where I should just keep any mappings out of?

@Ivan-Velickovic
Copy link
Collaborator

Apologies, I forgot to reply to this.

The mapping is not static no. The reserved regions (initial task image, PD images, kernel image) are allocated from the start of RAM which is at physical address 0x0 on the ZCU102 so if you make your DMA regions say 0x10000000 or higher it should be fine unless you have more than 256MiB of PD ELFs to load.

I know how annoying this must be since you are relying on the tool to produce a valid image and not have to check this kind of thing yourself. There will be a release within the next couple of weeks, I will make sure to solve this before then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants