[U-Boot] [PATCH v2 0/5] Enable caches for the RPi2

[Alexander Graf]

> Am 17.03.2016 um 05:26 schrieb Stephen Warren <swarren at wwwdotorg.org>:
> 
>> On 03/16/2016 08:41 AM, Alexander Graf wrote:
>> This patch set converts the Raspberry Pi 2 system to properly make use of
>> the caches available in it.
>> 
>> Because we're running in HYP mode, we first need to teach U-Boot how to
>> make use of HYP registers and the LPAE page layout which is mandated by
>> hardware when running in HYP mode.
>> 
>> Then while we're at it, also mark the frame buffer cached to speed up
>> screen updates.
>> 
>> With this patch set, my Raspberry Pi 3 running in AArch32 mode is a *lot*
>> faster than without.
>> 
>> Please verify that the code works on a RPi2 as well and doesn't break the
>> original Pi. In theory it should work, but I only have a 3 to test on
>> available here.
> 
> This series mostly works OK. I found the following results, with my rpi_dev branch on github if you want to test the exact same commits:
> 
> RPi B+ (running rpi_1 build):
> - Very minor transient corruption when running "ls mmc 0:2 /etc"
> 
> RPi 2 (running rpi_2 build):
> RPi 3 (booting in 32-bit mode and running rpi_2 build):
> RPi 3 (booting in 32-bit mode and running rpi_3_32b build):
> - Obvious transient corruption when running "ls mmc 0:2 /etc"
> 
> RPi 3 (booting in 64-bit mode and running rpi_3 build):
> - No issues
> 
> I suspect the transient corruptions that I saw were missing cache flush operations; during the large "memcpy" while scrolling the LCD, I would see corruption in the copied data. This would soon disappear; presumably as new data is written to the bottom lines of the frame-buffer flushes out old cache lines while doing a write-allocate?
> 
> Still, I'm not 100% sure this is an issue with these patches since the RPi B+ has a similar (although much less obvious) issue. Perhaps U-Boot is using the wrong VC/GPU cache alias (top 2 bits of 32-bit physical address) for the frame-buffer, i.e. the issue is in the GPU cache, not in the ARM cache?
> 
> As far as I can tell, USB worked fine in all cases (at least, the on-board hub/Ethernet device seemed to be enumerated without issue according to "usb tree" and "usb info".)
> 
> As such, I'm tempted to just ack the patches, but it'd be nice if you could take a look and see if something obvious is wrong.

Could you please take all patches except for the one that actually sets the dcache policy in the video driver? That way we already get the non-fb speedups for rpi2/3 and I can check where the corruption comes from in parallel with a smaller patch queue.


Alex