Enable caches for the RPi2

We want to be able to reuse device drivers from 32bit code, so let's add definitions for all the dcache options that 32bit code has.

While at it, fix up the DCACHE_OFF configuration. That was setting the bits to declare a PTE a PTE and left the MAIR index bit at 0. Drop the useless bits and make the index explicit.

Signed-off-by Alexander Graf <[email protected]>

We currently always modify the SVC versions of registers and only support the short descriptor PTE format.

Some boards however (like the RPi2) run in HYP mode. There, we need to modify the HYP version of system registers and HYP mode only supports the long descriptor PTE format.

So this patch introduces support for both long descriptor PTEs and HYP mode registers.

Signed-off-by Alexander Graf <[email protected]>

When compiling the code for 64bit, the lcd code emits warnings because it tries to cast pointers to 32bit values. Fix it by casting them to longs instead, actually properly aligning with the function prototype.

Signed-off-by Alexander Graf <[email protected]>

Now that we have support for running with caches enabled in HYP mode, opt in to that on the Raspberry Pi 2. This brings a significant performance boost.

Signed-off-by Alexander Graf <[email protected]>

The bcm2835 frame buffer is in RAM, so we can easily map it as cached and gain all the glorious performance boost that brings with it.

Am 24.03.2016 um 03:05 schrieb Stephen Warren <[email protected]>:

Quoted 3 lines · Alexander Graf

The bcm2835 frame buffer is in RAM, so we can easily map it as cached and gain all the glorious performance boost that brings with it.

Tested-by Stephen Warren <[email protected]>

Quoted 3 lines

drivers/video/bcm2835.c +0 -0

@@ -44,6 +44,7 @@ void lcd_ctrl_init(void *lcdbase)

drivers/video/bcm2835.c void lcd_ctrl_init(void *lcdbase) · line 116

Quoted 6 lines

drivers/video/bcm2835.c +6 -0

+    /* Enable dcache for the frame buffer */
+    fb_start = ALIGN(gd->fb_base, 1 << MMU_SECTION_SHIFT);
+    fb_end = gd->fb_base + msg_setup->allocate_buffer.body.resp.fb_size;
+    fb_end = ALIGN(fb_end, 1 << MMU_SECTION_SHIFT);
+    mmu_set_region_dcache_behaviour(fb_start, fb_end - fb_start,
+        DCACHE_WRITEBACK);

Shouldn't the start be rounded down and the end be rounded up to cover the entire FB RAM? Normally it might be problematic to push the boundaries outside the relevant data block since it would affect adjacent memory that might not then be aware of the cache setup. However, since the entire FB is in the VC portion of RAM and U-Boot is touching nothing else there, it should be fine in this case. (And even if it wasn't, the two ALIGNs would still want to move in opposite directions; start up and end down).

The bcm2835 frame buffer is in RAM, so we can easily map it as cached and gain all the glorious performance boost that brings with it.

The bcm2835 frame buffer is in RAM, so we can easily map it as cached and gain all the glorious performance boost that brings with it.

Signed-off-by Alexander Graf <[email protected]>

Tested-by Stephen Warren <[email protected]>

Acked-by Stephen Warren <[email protected]>

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.

Am 17.03.2016 um 05:26 schrieb Stephen Warren <[email protected]>:

Quoted 11 lines · Alexander Graf

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.

Quoted 6 lines

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.

Quoted 10 lines · Alexander Graf

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.

Quoted 6 lines

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.

Quoted 31 lines · Stephen Warren

Quoted 10 lines · Alexander Graf

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.

Quoted 6 lines

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

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?

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.

Quoted 10 lines · Alexander Graf

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.

Quoted 6 lines

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.

I did find one quirk with this series (as tested in my rpi_dev branch on github): HDMI console scrolling is now extremely fast for 32-bit builds. However, it's noticeably slower on the 64-bit RPi 3 build. I wonder if the DCACHE_* constants aren't optimal for AArch64? Perhaps this can all be explained instead by RPi 3 needing a slower core clock to support a fixed mini UART frequency; that probably slows down the ARM access to DRAM.