Absorbed in Elysium,
I will try to answer your questions one by one, but note: it would be nice to get a textbook for an OS course or an introductory course in computer architecture.
MMU consists of some hardware logic and state, the purpose of which is to create a physical address and provide / receive data to the memory controller and vice versa. In fact, the job of translating memory is the one that took care of the interaction of hardware and software (OS) mechanisms (at least on modern PCs). Once the physical address is received, the processor essentially does its job and now sends the address to the bus, which at some point is connected to the actual memory chips. In many systems, this bus is called the front bus (FSB), which, in turn, connects to the memory controller. This controller takes the physical address provided by the CPU and uses it to interact with DRAM chips and ultimately extracts the bits into the correct rows and columns of the memory array. Then the data is sent back to the CPU, which can now work on it. Please note that I do not include caching in this description.
So no, the MMU does not interact directly with the RAM, which I assume you use to refer to physical DRAM chips. And you cannot tell the MMU that you want 8 bytes, or 24 bytes, or something else, you can only provide an address. How many bytes you receive depends on which one you are on, and whether it is byte or address.
Your last question prompts me to remind you: MMU is actually part of the processor - it sits on the same silicon matrix (although this is not always the case).
Now let's look at your page error example. Suppose our user level application wants, as you said, set someAddress = 10, I will do it step by step. Suppose someAddress is 0xDEADBEEF and now ignores caches.
1) The application issues the storage instruction 0xsomeAddress, which in x86 might look something like
mov %eax, 0xDEADBEEF
where 10 is the value in the eax register.
2) 0xDEADBEEF in this case is the virtual address to be translated. In most cases, translating a virtual to a physical address will be available in a hardware structure called Buffer Lookaside Buffer (TLB), which will provide us with this translation very quickly. As a rule, he can do this in one measure. If the translation is in a TLB called a TLB hit, execution can continue immediately (that is, the physical address corresponding to 0xDEADBEEF, and a value of 10 is sent to the memory controller to be written).
3) Assume, however, that the translation was not available in the TLB (called the TLB pass). Then we must find the translation in the page tables, which are structures in memory, the structure of which is determined by the equipment and controlled by the OS. They simply contain entries that map the virtual address to the physical (more precisely, the virtual page number to the physical page number). But these structures are also in memory, and therefore must have addresses! The hardware contains a special register cr3, which contains the physical address of the current page table. We can index this page table using our virtual address, so the hardware takes a value in cr3, calculates the address by adding an offset, and goes into memory to retrieve the page table entry (PTE). This PTE will (hopefully) contain the physical address corresponding to 0xDEADBEEF, in which case we put this mapping in the TLB (so that we do not need to leaf through the page table again) and continue on our way.
4) But oh no! What if there is no PTE in the page tables for 0xDEADBEEF? This is a page error, and this is where the operating system comes into play. The PTE that we left the page table existed because it had (let's say) a valid memory address for access, but the OS had not yet created a VA-> PA mapping for it, so it would have a bit set to indicate that it is not valid. The hardware is programmed in such a way that when it sees this invalid bit on access, it throws an exception, in this case a page error.
5) The exception leads to the fact that the hardware calls the OS, jumping to a known location - a piece of code called a handler. There can be many exception handlers, and one of them is the page error handler. The page error handler recognizes the address that caused the error because it is stored somewhere in the register and therefore will create a new mapping for our virtual address 0xDEADBEEF. He will do this by allocating a free page of physical memory, and then say that "all virtual addresses between VA x and VA y will be mapped to some address on this newly allocated page of physical memory." 0xDEADBEEF will be somewhere in this range, so matching is now safe in page tables, and we can restart the statement that caused the page error (mov).
6) Now, when we go back to the pages of the tables again, we will find the mapping, and the PTE we pull out will have a good physical address that we want to save. We provide this with a value of 10 for the memory controller, and you're done!
Caches will change this game a bit, but I hope this helps to illustrate the paging experience. Again, it will be very useful for you to familiarize yourself with some OS / Computer Architecture books. Hope this was clear.