logical_to_physical doesn't cope with section-mapped regions

Here’s something interesting I’ve just found; the logical_to_physical function in the kernel source (which is used by OS_Memory 0 & RISCOS_LogToPhys) doesn’t cope with memory which has been section mapped, because it only looks in the level 2 page table (Section mapped memory only uses the level 1 page table). Is this an oversight or is there some hidden reasoning behind the code not checking L1PT? In practical terms, it means that any logical-to-physical translation on the ROM address space or the IO address space (as allocated by OS_Memory 13/14 or RISCOS_MapInIO) will fail.

It looks like logical_to_physical ignores large pages (and tiny/extended pages) too.

Although it looks easy enough to add support for all the different page types, it looks like we might run into difficulty if someone uses OS_Memory 13/14 to map in a block of RAM. If you tried using OS_Memory 0 to alter the cacheability of the page, then insteead of failing like it would do for any other section-mapped region, it would leave the section-mapped entry alone and end up modifying the ‘true’ mapping of the page instead. This is because the section-mapped instance would have a physical address that’s contained in PhysRamTable, something that ordinarily only 4K mapped pages would have.

For the moment, I’ve gone down the route of changing RISCOS_LogToPhys to perform its own L1PT lookup. This is enough for the current IOMD ROM to work properly, but it still won’t work with large/tiny/extended pages, and it doesn’t go any way towards fixing OS_Memory 0. Maybe the best course of action would be to just add a new reason code, so we don’t have to worry about any knock-ons caused by changing the behaviour of the old code.