OS_Memory 13 issue

Is there a problem with OS_Memory 13?

repro:

MODE 13
SYS "OS_CallAVector",,,,,9,,,,,42 TO A%
SYS "OS_Memory",13+(1<<17),A%,320*256*8 TO ,,,Z%
DIM P% 64:!P%=148:P%!4=-1:SYS "OS_ReadVduVariables",P%,P%:PRINT ~!P%; ~Z%

Pseudo of the above:
Change mode
Get the screen buffer hardware address
Map additional IO memory to the screen buffer and get the logical address
Display the screen logical address used by the display driver and the address OS_Memory 13 mapped the IO memory too

It was my understanding (although it’s not formally documented) that OS_Memory 13 will reuse the existing logical address when remapping IO memory if there’s enough space to do so. I’d expect the OS_Memory 13 call to extend the existing buffer in the case above, instead its double mapping the IO to a new logical address.

The side effect of this is that if you go to MODE 13 and get it’s logical address, then go to MODE 15 and get it’s logical address. The screen is mapped into two logical addresses, each mode change is potentially leaking logical memory space.

In addition to this, how does one unmap IO memory?

It was my understanding (although it’s not formally documented) that OS_Memory 13 will reuse the existing logical address when remapping IO memory if there’s enough space to do so.

Correct. However, it will only reuse the existing mapping if the attributes match – and in this case the attributes you’re requesting don’t match the ones used by the kernel when it maps in the memory (bufferable, doubly mapped, full user mode access).

The side effect of this is that if you go to MODE 13 and get it’s logical address, then go to MODE 15 and get it’s logical address. The screen is mapped into two logical addresses, each mode change is potentially leaking logical memory space.

Assuming you’re talking about the Pi here – part of that could be down to the fact that the GPU is in control of the framebuffer physical address. When changing mode it will often (always?) give a different address to before.

In addition to this, how does one unmap IO memory?

You can’t (unless you use OS_Memory 14 & 15 – but then you’d be limited to mapping in 1MB at a time, at 1MB alignment). I believe the OS_Memory 13 was originally designed as a way of allowing hardware drivers to map in the hardware registers that they need to access. There’s only so many hardware registers in a system, and you’d generally want the hardware driver to be running for the entire time the machine is turned on, so there’s little point in providing the ability to map out the memory.

For the Iyonix this worked fine for video (there’s a finite amount of VRAM on the graphics card, so the OS is able to map in all of it on startup), but for the Pi it’s a bit messier due to the way the GPU manages the memory allocation. I think the main problem is that the kernel asks for a doubly-mapped region, which will significantly reduce the chances of being able to reuse an older mapping (if the address matches but the size doesn’t, the old mapping won’t be suitable because the second mapping will be incorrect). Double mapping for both the Pi and the Iyonix is pretty pointless anyway, since neither machine supports VIDC-style hardware scrolling. However I suspect a few bits in the VDU drivers would need fixing if we were to turn it off, and if we turned it off then it wouldn’t solve all of our problems – it would allow us to map in all of the videocore memory in one go, ensuring no new mappings are needed later, but we’d be giving full usermode access to the GPU’s workspace, which is just asking for trouble. So in the long-term, some way of unmapping the memory probably is required.

Correct. However, it will only reuse the existing mapping if the attributes match – and in this case the attributes you’re requesting don’t match the ones used by the kernel when it maps in the memory (bufferable, doubly mapped, full user mode access).

That will explain it the double mapping then.

Assuming you’re talking about the Pi here – part of that could be down to the fact that the GPU is in control of the framebuffer physical address. When changing mode it will often (always?) give a different address to before.

Sorry I should have said it was on the Pi. It doesn’t cause me any problems, its just something I observed whilst mapping in GPU memory under GraphicsV. The physical does shift around on mode changes and when that happens the previous logical block remains mapped and is essentially leaked.

It’s not a major issue, from the testing I’ve done swapping between MODE 13 / 15 and seeing what logical address it gets, it seems to settle on three logical blocks mapped at any one time and switches between them randomly on a mode change – F2C00000, F3000000, F3400000.