From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 13 Mar 2015 12:39:08 -0600 Subject: [U-Boot] [RFC PATCH] usb: dwc2: handle bcm2835 phys->virt address translations In-Reply-To: <201503131913.29922.marex@denx.de> References: <1426227189-30488-1-git-send-email-swarren@wwwdotorg.org> <201503131530.20684.marex@denx.de> <550311E9.3080808@wwwdotorg.org> <201503131913.29922.marex@denx.de> Message-ID: <55032ECC.3050805@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 03/13/2015 12:13 PM, Marek Vasut wrote: > On Friday, March 13, 2015 at 05:35:53 PM, Stephen Warren wrote: >> On 03/13/2015 08:30 AM, Marek Vasut wrote: >>> On Friday, March 13, 2015 at 07:13:09 AM, Stephen Warren wrote: >>>> 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. >>> >>> Caches aren't working on BCM2xxx or what's the reason for this hack ? >>> Or are these different (not on-CPU) caches we're talking about (yes, >>> I did notice the GPU Lx cache stuff)? >> >> Yes, the "GPU" has its own caches, entirely separate from the ARM core >> and at a different location in the system bus structure, and it seems as >> if at least some other peripherals other than GPU/graphics/VideoCore >> access DRAM via those caches too. >> >> There are some brief details in BCM2835-ARM-Peripherals.pdf, although it >> isn't terribly clear. > > Thanks for clearing this up. I suspect there's no way to turn those caches > off altogether, right ? But uh ... ew :( There may be, Search for disable_l2cache at http://elinux.org/RPiconfig. That option is read by the SoC's binary bootloader (which I believe 99%-100% runs on the VideoCore not ARM) and programmed before the ARM bootloader (U-Boot) is started. The disadvantages of the option are: * According to all descriptions of the option I've seen, it requires that SW that wishes to run with that option enabled must pass a different upper 2 bits of physical address to DMA engines. See for example the elinux.org link above and: https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bcm2708/include/mach/memory.h#L38 https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bcm2708/Kconfig#L43 * It's a system-wide option without any runtime control that I'm aware of, and so would affect anything U-Boot boots such as Linux, so Linux would need to be modified too. I assume it would reduce graphics performance at least. As such, I don't think we want to require that option.