I have hard coded the address change and that side of things has always worked. I have not noticed any problems talking to the various peripherals on the Pi 2.
Are you saying that to get reliable cache consistent memory I need to use the mailbox interface? There was no need to do so on earlier models.
Perhaps you should give me a link to your Pi2 code. I'm just guessing at what api's you are using.
The only relevant APIs are mmap to allocate blocks of virtual memory and /proc/pid/pagemap to find the physical address of userland virtual memory.
The DMA engine works off so called (VC CPU) bus addresses.
Allocate x pages of (ARM) virtual memory using mmap.
Use pagemap to find the (ARM) physical address of each page of (ARM) virtual memory (the virtual memory pages will be contiguous, the physical pages will not be).
Add 0x40000000 (Pi 1) or 0xC0000000 (Pi 2) to the (ARM) physical address to form the (VC CPU) bus address.
If we want DMA to copy a value to/from virtual memory we use the (VC CPU) bus address in the DMA control block destination/source fields.
In the past there was a slight modification to ensure the virtual memory was uncached. The disputed second mmap to physical memory + 0x40000000. From your comments it seems that the 0x40000000 was an error and indeed 0x00000000 has worked on a Pi 1.
Have a look at the servoblaster code I posted. It allocates DMA memory in functionally the same way as pigpio.
I should stress again that I have sort of working Pi 2 code using peripheral address 0x3F000000, physical to bus translation by adding 0xC0000000 and a second mmap with 0x00000000.
The problem is I have to add code which attempts to flush the cache (by using non-contiguous memory addresses to store data) and rather than set up the DMA control blocks once I have to set them up hundreds of times. All the symptoms of cache inconsistency. This all adds delays so rather than a program initialisation in a second we are talking of tens of seconds.