Stephen Warren <swar...@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.
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
