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

[Stephen Warren]

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.