View topic - TLB operation safety

by **SimonLothar** » Fri Jul 22, 2016 8:59 pm

lephe wrote:...which means it's an instruction access rather than a data access : possibly it may matter ?).

Though it is possible to read data from virtualized ROM, I did not manage to run code in virtualized RAM.

// Running code in physical RAM works:
*(unsigned int*)0x88040000 = 0x000BE056; // RTS MOV #h'56, r0
result = (*(int(*)(void))0x88040000)();

// Running code in virtualized RAM fails:
*(unsigned int*)0x08100218 = 0x000BE067; // RTS MOV #h'67, r0
result = (*(int(*)(void))0x08100218)(); // This leads to a system error

by **lephe** » Fri Jul 22, 2016 9:51 pm

I think I experimented this RAM-execution problem in early stages of development. I believe this was also in Kristaba's work (some of it being my starting point long ago). It is implicitly solved by the documentation demanding the vbr to reside in P1 or P2 space. Regarding my current errors, it should definitely be data access.

The MENU-key functionality is implicitly disabled the use of my own keyboard driver instead of GetKey() and related (for some reason the add-in aims at being free-standing). The system has virtually no opportunity to do any task-switching.

I'll try to workaround this issue by having the system load the entire TLB contents before setting up my interrupt handler. Reading the instruction data seems to work fine, I'll just hope the system will fill the three ways before overwriting existing entries, thus allowing virtualization of large add-ins (at least until 384k because the 8k static RAM messes up the thing).

Having this issue appearing when overwriting the system's vbr value leads me to think that the system actually handles TLB misses, at least some of the time. On the other hand, the 512k-limit for add-ins corresponds to the amount of memory, which can be mapped by the TLB at a given time. I know Kristaba did some interrupt handler disassembling, I'll ask for the TLB miss handler if I ever run into him.

Thanks for your help !

by **SimonLothar** » Sat Jul 23, 2016 12:47 pm

You raised my interest in TLB-things.
I tried Hmem_SetMMU (0x03FA) ... and failed.
Then I tried a syscall for reading the TLB-table (0x3F8; TLB_address_read) ... and failed, too.
It turned out, that certain TLB-syscalls (f. i. Hmem_SetMMU) are not properly implemented with fx9860-(SH-4)-calculators/OSes any more.

A bit concerned by this, I had a closer look:

At least the following syscalls are no longer supported with SH-4-based fx9xx0 calculators: Show

At least the following syscalls are no longer supported since OS 2.00 with fx9xx0 calculators: Show

by **lephe** » Sun Jul 24, 2016 9:03 am

That's quite bad news you've got there. I had seen already that the call to Hmem_SetMMU() invoked at add-in initialization had no actual effect, or was overridden by then system on SH3-based machines (in other words, there was no TLB entry matching the parameters given to the syscall), but I wouldn't expect it to be left non-implemented on SH7305.

I had a quick look and it's right that many of them are just "rts; nop". That's not the case for TLB_address_read() (0x3f8) Hmem_SetMMU() (0x3fa). Did you find any reason why they wouldn't work ?

Btw, I've got a local fork of your documentation from media.taricorp.net, but many of the syscalls you named are not listed there. Where can I find an up-to-date version of your work ?

by **SimonLothar** » Sun Jul 24, 2016 11:24 am

lephe wrote:I had a quick look and it's right that many of them are just "rts; nop". That's not the case for TLB_address_read() (0x3f8) Hmem_SetMMU() (0x3fa). Did you find any reason why they wouldn't work ?

They push some registers (r8-r14,macl,mach) onto the stack and immediately pop them back. They do not use any argument. They do not pass any return value. In other words they act like a simple rts/nop except that they consume some more time (concerns syscalls 0x03f8, 0x03f9, 0x03fa, 0x03fc, 0x03fd). These calls are not only useless, they consequently are not used throughout their OSes.

by **SimonLothar** » Sun Jul 24, 2016 11:35 am

lephe wrote:Btw, I've got a local fork of your documentation from media.taricorp.net, but many of the syscalls you named are not listed there. Where can I find an up-to-date version of your work ?

Most of the syscalls I listed to be not supported any more are still not considered in my documentation (and they won't, because they are not consistent). I automatically analyzed the new OSes with a small program to detect the newly indifferent syscalls, just in case someone should use one of these.

by **AmazoNKA** » Sun Jul 24, 2016 2:11 pm

Here is a more up to date version of the documentation by Simon fx_calculators_SuperH_based.chm (20)

by **lephe** » Sun Apr 15, 2018 7:12 pm

Sorry for bringing up such an old topic; I happen to have new information regarding the original problem - whether, as I believed, the system dynamically mapped the add-in, or, as you explained, it fully virtualized it from the start.

I've been investigating the system mappings on a recent SH4 machine (a Graph 75+E, which is really just an fx9860G II). It is now clear to me that the system only maps pages "on demand".

For my tests, I used a C routine to inspect the contents of the Unified TLB (UTLB) using the memory-mapped interface to the TLB provided by the MMU. I did not inspect the ITLB (there's a word about that at the end) and did not overwrite the system's interrupt handler as I usually do. This was a standard add-in.

The default add-in mappings only included :

One 4k-page at address 00300000
32k memory at address 08100000 (static RAM)
A single page mapped at 00000000 (!)

I included a large data array in my text segment and inspected the UTLB. Only the first page was mapped by default, regardless of the size of the array. Please note that the UTLB inspection code was fully contained in the first 4k page.

The most significant test consisted in accessing all the 4k-chunks of my big array in a random order and traversing the UTLB between each access. At each step, the system would map the accessed page, but no more.

As I thought, the system uses TLB miss exceptions to replace mappings if the UTLB is full. When I tried to access all the sections of an array larger than 4k (the only page size used by the system) * 64 (number of entries in the UTLB), it worked but the system had to replace some mappings. (At the end of execution, some of the array pages were not mapped anymore). Obviously the add-in was never fully virtualized because it did not fit in the UTLB.

Now, as you know, I was originally asking this question because I want to override interrupts (preventing the system from answering the TLB misses) without touching the MMU. In this setting, I would be limited to fully virtualized add-ins. Given that 9 UTLB entries are used by default, this leaves 4k * 55 entries = 220 kB for the add-in, which I experimentally confirmed to be the limit.

As I mentioned, I did not inspect the ITLB at all (although it looks reasonable for code) because when the ITLB misses, the requested address is looked up for in the UTLB and, if I'm not mistaken, if the UTLB hits the entry is copied to the ITLB. This means that the ITLB cannot be used to extend the amount of mapped code.

I think this provides enough evidence for my original hypothesis. If you have information regarding the mapping of virtual address 00000000 to physical address 00000000 (with user+kernel read+write protection bits), I'd appreciate any insight.

View topic - TLB operation safety

TLB operation safety

Re: TLB operation safety

Re: TLB operation safety

Re: TLB operation safety

Re: TLB operation safety

Re: TLB operation safety

Re: TLB operation safety

Re: TLB operation safety

Re: TLB operation safety

Who is online