Stephen Warren swarren@wwwdotorg.org writes:
BCM2835 bus addresses use the top 2 bits to determine whether peripherals use or bypass the GPU L1 and L2 cache. BCM2835-ARM-Peripherals.pdf states that:
0: L1 & L2 cached 4: L2 cache coherent (non allocaing) 8: L2 cached only c: Direct uncached.
That document also states that "Software accessing RAM using the DMA engines must use bus addresses (base at 0xc0000000). However, this appears to be incorrect since it does not work in practice on the bcm2835 (although it does on bcm2836). "usb start" causes some EABI function to call raise(8), presumably due to corrupted USB IN data (the converse is true on bcm2836; a value of 4 causes signals). However, I haven't investigated the cause.
A value of 4 matches what the RPI Foundation's kernel; see the definition of _REAL_BUS_OFFSET in arch/arm/mach-bcm2708/include/mach/memory.h. With the code updated to implement a phys->bus translation by setting the top two bits of DWC2 DMA addresses to 4, USB keyboard support appears stable.
A similar change is made for bcm2836 (RPi 2). I can't justify this value since it doesn't match the RPi Foundation kernel. However, it does appear to work for the built-in USB Ethernet at least.
Ideally, the bcm2835 SoC support would provide some common function for any DMA-capable driver to call to perform the phys->bus translation, rather than placing ifdefs in each driver file. However, I can't find such a standard function in U-Boot.
Huh. Agreed that it seems like it should be 0xc top bits on both, but I guess whatever works.
It does seem like we ought to have some vtophys / vtobus functions.