I/O memory access and hardware page mappings

[Adam Lackorzynski]

Hi Paul,

On Mon Jul 24, 2017 at 16:55:37 +0200, Paul Boddie wrote:
> Having looked at the l4vbus_gpio functions and struggled with providing 
> suitable devices, I decided to take the simpler approach and just ask for the 
> I/O memory of the devices and access that directly. However, this didn't prove 
> as straightforward as anticipated, either.
> 
> The aim was to take the previously-mentioned device resources of the following 
> form and to perform l4io_request_iomem (or l4io_request_resource_iomem) to get 
> addresses of virtual regions corresponding to the different physical memory 
> regions.
> 
>     PORTA = Hw.Device(function()
>       Property.hid = "jz4780-gpio-PORTA";
>       Resource.regs = Res.mmio(0x10010000, 0x100100ff);
>       ...
>     end);
> 
>     PORTB = Hw.Device(function()
>       Property.hid = "jz4780-gpio-PORTB";
>       Resource.regs = Res.mmio(0x10010100, 0x100101ff);
>       ...
>     end);
> 
>     ...
> 
>     PORTF = Hw.Device(function()
>       Property.hid = "jz4780-gpio-PORTF";
>       Resource.regs = Res.mmio(0x10010500, 0x100105ff);
>       ...
>     end);
> 
> It was indeed possible to obtain the resources involved with individual ports 
> and also to obtain an address for each port region. However, accesses relative 
> to these base addresses did not produce the expected results (LED output 
> changes, switch input changes).
> 
> (Looking at the virtual and physical regions in jdb suggested that the 
> accesses were not being propagated, although I was also not successful in 
> putting values into physical memory addresses and obtaining any of the 
> expected results, either.)
> 
> Now, I did wonder how such a small, 256-byte region mapping would actually 
> work with my hardware. The JZ4780 does not support pages smaller than 4K when 
> mapping memory, but I did notice that I do get an exception if trying to 
> access beyond the end of the virtual region.
> 
> (I found this out when considering that perhaps the virtual address might 
> actually point to the base of the hardware page containing the region. So, I 
> added a region offset to the base and tried to perform a memory access. 
> Obviously, returning the hardware page address would be an unfortunate choice 
> because it would oblige the API user to know about such things. Clearly, the 
> API should return the address of the actual region, and maybe it does.)
> 
> So, if this smaller-than-hardware page size is enforced, there must be a 
> mechanism above the plain TLB mechanism that performs such enforcement. One 
> interesting thing I noticed was that when requesting two different regions, 
> the virtual addresses for the base of the regions were 4K apart, not 256 bytes 
> apart. In any case, I was left wondering if any such mechanism might be 
> preventing accesses from being correctly propagated.
> 
> To simplify things a bit more, I then decided to just define the entire GPIO 
> region in the device tree:
> 
>   GPIO = Hw.Device(function()
>     Property.hid = "JZ4780 GPIO";
>     Resource.regs = Res.mmio(0x10010000, 0x100105ff);
>   end);
> 
> Requesting the memory for this device succeeds as before, but then performing 
> accesses relative to the returned virtual address (with port F at vaddr + 
> 0x500, for instance) also succeeds and produces the desired result, unlike 
> before.
> 
> So, what is this mechanism that handles accesses to regions that do not 
> correspond to hardware pages (either in size or alignment)? Is there some kind 
> of address-based trapping that redirects accesses to some kind of privately-
> allocated page that is then mapped to the hardware page concerned? Is it 
> possible that this mechanism does not work on MIPS or on my specific device?

There's no mechanism here that handles MMIO region sizes smaller than
page size. Rather, l4io_request_iomem and friends to not handle
addresses with offsets very well. Obviously I'll fix this.
For now, please just use page-aligned physical addresses (and size).



Thanks,
Adam