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

[Alexander Graf]

On 17.03.16 05:26, Stephen Warren wrote:
> 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.

Ugh. It helps when you get the parameters for ALIGN() correctly.

Please just squash the patch below into the last patch, then things
should work fine. If you like I can resend a v3, but I guess the change
is small enough?


Alex

diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index fe49f2e..40fc418 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -109,7 +109,7 @@ void lcd_ctrl_init(void *lcdbase)

        /* Enable dcache for the frame buffer */
         mmu_set_region_dcache_behaviour(gd->fb_base,
-               ALIGN(PAGE_SIZE,
msg_setup->allocate_buffer.body.resp.fb_size),
+               ALIGN(msg_setup->allocate_buffer.body.resp.fb_size,
PAGE_SIZE),
                DCACHE_WRITEBACK);
        lcd_set_flush_dcache(1);
 }