Fix ZCU board.py paddr_top constant.

[cazb2]

See line 2115 in zcu102.dts

PS. Why do we not parse the dts to retrieve information like this?

[midnightveil]

Was there a particular reason you are running into the issue with this paddr_top? The value we use does not necessarily have to be the actual paddr top.

And yes, sdfgen should really parse the DTS for this information.

But actually: it should not need to know the memory layout of the platform for RAM memories at all, otherwise we end up having to emulate the behaviour of the microkit tool. It's only because at the moment when we use sdfgen for generating the configs it expects to itself know the physical addresses of e.g. DMA buffer regions, when really that should be something we learn from microkit at runtime. This is why it doesn't work for x86 for example.

[cazb2]

Was there a particular reason you are running into the issue with this paddr_top? The value we use does not necessarily have to be the actual paddr top.

I assume it has to be <= the actual paddr top though...
When running the ethernet driver the board will hang upon accessing the "dma" region

And yes, sdfgen should really parse the DTS for this information.

But actually: it should not need to know the memory layout of the platform for RAM memories at all, otherwise we end up having to emulate the behaviour of the microkit tool. It's only because at the moment when we use sdfgen for generating the configs it expects to itself know the physical addresses of e.g. DMA buffer regions, when really that should be something we learn from microkit at runtime. This is why it doesn't work for x86 for example.

Yep I totally agree idk, on top of that my understanding is if we use an IOMMU then microkit would not have to treat "DMA" regions any differently to normal memory avoiding this contiguous physical address requirement issue.

[midnightveil]

I assume it has to be <= the actual paddr top though...

Ah, right. Yes I read the commit backwards, you're decreasing it. Unsure how anything ever worked then on the ZCU...?

If we use an IOMMU then microkit would not have to treat "DMA" regions any differently to normal memory avoiding this contiguous physical address requirement issue.

This isn't really anything to do with the IOMMU at all, just information flow from the build system configuration to the runtime address layout of the system.

[cazb2]

I assume it has to be <= the actual paddr top though...

Ah, right. Yes I read the commit backwards, you're decreasing it. Unsure how anything ever worked then on the ZCU...?

If we use an IOMMU then microkit would not have to treat "DMA" regions any differently to normal memory avoiding this contiguous physical address requirement issue.

This isn't really anything to do with the IOMMU at all, just information flow from the build system configuration to the runtime address layout of the system.

I'm not sure I follow but I believe you.

I guess on a tangential thought, at the moment in our systems we are forced to set a physical address for dma regions simply because the microkit/capdl only guarantees contiguity for physical addressable memory, however this is theoretically avoidable with an iommu since it can virtualise the address space for devices hence making non-contiguous physical memory look contiguous and therefore avoid the need to handle this as a special case... potentially...

[midnightveil]

I guess on as a tangential thought, at the moment in our systems we are forced to set a physical address for dma regions simply because the microkit/capdl only guarantees contiguity for physical addressable memory

This really should be an explicit control, I think.

[Ivan-Velickovic]

Most of the time you don't care where the physical memory actually is, you just want a contiguous region. The only way to do that in the Microkit right now is to use setvar with region_paddr but that's not ideal for our case here where we have the configuration structs.

I think it's becoming clear that there needs to be a more generic way to give user-space the run-time determined value of things like memory region physical addresses. On x86 it's still more complicated because we now have to have a way for the capDL initialiser to also pass this kind of information at run-time to Microkit which is a bit annoying.

[Ivan-Velickovic]

Ah, right. Yes I read the commit backwards, you're decreasing it. Unsure how anything ever worked then on the ZCU...?

ZCU102 was only tested for timer/serial I believe where there's no DMA used so that's why it didn't get noticed I assume.

[Ivan-Velickovic]

And yes, sdfgen should really parse the DTS for this information.

The whole paddr_top thing was just a hack and I never got around to fixing it properly.