Determining L2PT descriptor format
Jon Abbott (1421) 2601 posts |
How can I determine if L2PT is using Large, Small, Extended Small/Tiny page descriptors? At the minute, I’m assuming 80321 and earlier are using Small and later CPU’s are using Extended small or Tiny, but this might be wrong or change in the future. I need to determine how many AP’s there are in the descriptor and the page size. Page size I’m assuming matches the page size I get from RISC OS across the whole memory map. I should add that looking at [1..0] for the page descriptor type doesn’t really help as the Pi1 for example doesn’t support AP3..AP0 having different values (the PRM says “The use of subpage AP bits where AP3, AP2, AP1, and AP0 contain different values is deprecated.”) |
Rick Murray (539) 13406 posts |
Any help here? https://github.com/dwelch67/raspberrypi/tree/master/mmu |
Jon Abbott (1421) 2601 posts |
I was thinking more RISCOS specific, I couldn’t see anything obvious in OS_ReadSysInfo 6 OS_PlatformFeatures 0 bit 15 is “CPU supports extended small page L2 descriptors” – do I presume that if this is 0, RISCOS is using Small descriptors? And at which OS build was this added? Can I safely assume if the SWI errors it’s Small descriptors? If the Pi build always uses extended Small, then I can ignore the “AP3..AP0 must be identical” issue. |
Rick Murray (539) 13406 posts |
If you’re reading the page table directly, doesn’t the entry in the L1PT tell you what the L2PT format is? |
Jon Abbott (1421) 2601 posts |
OS_PlatformFeatures 0 has bit 15 clear on the Pi – is that correct? L2PT entries on the Pi only contain one AP, as far as I can tell.
As I mentioned in the OP, the L2PT entry contains its format but doesn’t inform you if AP3..AP0 work. |
Rick Murray (539) 13406 posts |
If it helps, the Pi2 (original ARMv7) replies &800037F9, which breaks down as: Bit 0 – needs the SyncCodeAreas call Bit 11 is highlighted as it is incorrect. The Pi2 (ARMv7) does support SWP. Test code:
When run, prints: >RUN 12345678 12345678 FF > That is to say, |
Jon Abbott (1421) 2601 posts |
My query was how to determine the number of AP’s in the L2PT descriptors and if they can contain different values. |
Rick Murray (539) 13406 posts |
Quote:
I got a little sidetracked by the surprise of seeing the SWP instruction flagged as not available, but the basic gist of my post was to point out that bit 15, the extended small page descriptors, is not set on an ARMv7 Pi2, thus meaning that the Pi build does not always use extended small (or doesn’t set the flag?). |
Jon Abbott (1421) 2601 posts |
Either it’s that way because ARM ARM says it’s deprecated (try configuring the CPU for ARMv5 mode), or it returns the wrong value on the earlier Pi’s. |
Rick Murray (539) 13406 posts |
There’s no ARMv5 mode on the Pi2 (that’s the Pi1). Maybe given its deprecated nature and the fact that the ARMv8 (Pi3, later Pi2) doesn’t support it at all, ROOL decided to just flag it as unavailable? |
Jeffrey Lee (213) 6046 posts |
Extended small pages are an XScale-ism. I don’t believe they’re supported by any CPU which RISC OS currently supports (only the 80200 has the flag enabled). IIRC a while ago I did try enabling it for the 80321 (since it would have made a couple of extra cache policies available to us?), but found that the resulting ROM didn’t boot, so I assumed either the feature isn’t supported on 80321 (contrary to the manuals I’ve seen) or RISC OS’s support for the feature was broken, and so I just turned the flag back off again. I don’t believe there are any SWIs to reveal which page table format RISC OS is using (since page table manipulation should generally only be performed by the kernel). So you’ll have to work it out by looking at the ARM/CPU architecture (e.g. ARM6 has the “updatable” flag) and the relevant CP15 registers (e.g. bit 23 of the ARMv6 SCTLR, to select between legacy & new page table format; although RISC OS 5 will always use the new format). The main thing to bear in mind is that there are often multiple ways of encoding the same thing in the page tables, and the methods that RISC OS use may change over time, so you might have to implement logic which fully decodes things according to the rules laid out in the ARM ARM, rather than assuming that the OS does things on one specific way (e.g. when I added cacheable pagetable support I changed the OS to use a different way of encoding the cache policies). For old-style small pages, I think RISC OS 5 always uses the same values for AP0..3. But I can’t comment for other OS versions, and I know there are some apps which will tweak the settings of some pages (e.g. Adrian Lees’ Prot1K) If it helps, the Pi2 (original ARMv7) replies &800037F9, which breaks down as:
Bit 11 is not set, nothing is wrong. |
Rick Murray (539) 13406 posts |
Phew! Must have miscounted the bits in SciCalc. Now if that program could export the result to an editor… ;-) |
Jon Abbott (1421) 2601 posts |
Is there a legal way to set page/subpage access, so I don’t have to alter L2PT direct? I need to set USER access to a logical address range within application space, to either R or R/W.
3.5 thru 3.71 use the same value in AP3..0, 3.8 and 4.x (probably 6.x as well) set subpage access specifically on page zero; in general however RISC OS ignores subpages across all vesions. At hardware level, ARM6,7,8 macrocells, StrongARM and 80321 support subpages. I suspect all Intel ARM’s support subpages, but I don’t have documentation on them to confirm. Emulation wise, Red Squirrel supports subpages but doesn’t emulate subpage access permissions quite correctly and RPCEmu doesn’t support them at all. RPCEmu uses the CPU privilege level for page access permission checks and completely ignores the permissions set at page level. |
Jeffrey Lee (213) 6046 posts |
The closest thing to what you want (for arbitrary memory locations) would be OS_SetMemMapEntries, with the usual caveats that (1) all sub-pages will be set to the same access, and (2) it doesn’t always do the right thing on 3.5 and above (may clobber any new page flags that were introduced in 3.5+) If you’re only modifying application space I expect it will work fine, other areas might be a bit dodgy. |
Jon Abbott (1421) 2601 posts |
I’ve avoided that particular SWI ever since I discovered the flag corruption all those years ago, it also requires physical page numbers so I’d have to do logical translation first. The best idea I suppose is to implement it on newer hardware where I’m throttling the CPU (post 80321) and stick with direct L2PT for legacy CPU’s which support subpages. At least that way it’s future proofed, which is my main concern. |