dcache support for Raspberry Pi 1

fatload mmc 0:1 ${kernel_addr_r} zImage

This is effectively the same code but it also does a clean cache before invalidating and doing a memory barrier.

Quoted 2 lines

This is effectively the same code but it also does a clean cache before invalidating and doing a memory barrier.

Is it possible to share this function with arm1136 rather than cut/pasting it? I guess it's pretty small so not a huge deal, but still.

The code is copied 1:1 from arm1136 which uses the same cp15 registers.

Quoted 1 line

The code is copied 1:1 from arm1136 which uses the same cp15 registers.

Same comment here. Perhaps create a cache-armv6.c (or whatever name is appropriate; I'm not sure if ARMv6 mandates caches work this way, or if ARM11 is a better name, or ...?

On Friday 10 July 2015, 23:21:32 wrote Stephen Warren:

Quoted 6 lines · Alexander Stein

Quoted 1 line

The code is copied 1:1 from arm1136 which uses the same cp15 registers.

Same comment here. Perhaps create a cache-armv6.c (or whatever name is appropriate; I'm not sure if ARMv6 mandates caches work this way, or if ARM11 is a better name, or ...?

I know that cortex-m0 and cortex-m1 are also ARMv6(-M). I have no idea how cache works there or even if there is any. I think ARM11 seems more suitable for me. But where to put? Currently each CPU core has it's own directory.

cache flushing addresses must be cacheline size aligned, so mask the start and stop address appropriately.

When using dcache the setup data for the mailbox must be actually written into memory before calling into firmware. Thus flush and invalidate the memory.

Now that mailbox driver supports cache flush and invalidation, we can enable dcache.

Quoted 2 lines

Now that mailbox driver supports cache flush and invalidation, we can enable dcache.

Did you also test that HDMI output doesn't show any issues after this change? I think there's already cache-flushing in the LCD console code, so it should be fine, but best to check.

On Friday 10 July 2015, 23:24:58 wrote Stephen Warren:

Quoted 7 lines · Alexander Stein

Quoted 2 lines

Now that mailbox driver supports cache flush and invalidation, we can enable dcache.

Did you also test that HDMI output doesn't show any issues after this change? I think there's already cache-flushing in the LCD console code, so it should be fine, but best to check.

I don't use HDMI on my board, just serial and SSH.
But how may this affect that code if it is already flushing caches?

dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to 12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just get error messages about non-cacheline aligned address upon invalidation.

The performance stucks at 1.2 MiB/s.

This was tested by the following command:

Quoted 1 line

fatload mmc 0:1 ${kernel_addr_r} zImage

Alexander Stein (5):
arm1176/cpu: Match cache_flush to arm1136 arm1176/cpu: Add icache and dcache support arm1176/cpu: Align cache flushing addresses to cacheline size arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw
mailbox
arm/rpi: Enable dcache

 arch/arm/cpu/arm1176/cpu.c   | 114 +++++++++++++++++++++++++++++++++++++++++--
 arch/arm/mach-bcm283x/mbox.c |   6 +++
 include/configs/rpi-common.h |   1 -
 3 files changed, 116 insertions(+), 5 deletions(-)

Signature · 1 line

2.4.5

Quoted 3 lines · Alexander Stein

dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to 12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just get error messages about non-cacheline aligned address upon invalidation.

Could it be that code needed to support dcache is not the same for rpi_2's bcm2836 than it is for rpi's bcm2835?

Anyway: if code properly handles unaligned addresses then it should not throw an error message about it. Can you look into why the error is thrown?

static void v7_dcache_inval_range(u32 start, u32 stop, u32 line_len)

{
	/*
	 * If start address is not aligned to cache-line do not
	 * invalidate the first cache-line
	 */
	if (start & (line_len - 1)) {
		printf("ERROR: %s - start address is not aligned - 0x%08x\n",
			__func__, start);
		/* move to next cache line */
		start = (start + line_len - 1) & ~(line_len - 1);
	}

Hello Albert,

On Monday 06 July 2015, 09:39:40 wrote Albert ARIBAUD:

Quoted 9 lines

Quoted 3 lines · Alexander Stein

dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to 12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just get error messages about non-cacheline aligned address upon invalidation.

Could it be that code needed to support dcache is not the same for rpi_2's bcm2836 than it is for rpi's bcm2835?

Sure, bcm2835 is a armv6 while bcm2836 is a armv7.

Quoted 3 lines

Anyway: if code properly handles unaligned addresses then it should not throw an error message about it. Can you look into why the error is thrown?

Apparently it does not handle non-cacheline aligned addresses transparently or silently.

Here is the part of the code:

Quoted 12 lines

static void v7_dcache_inval_range(u32 start, u32 stop, u32 line_len)

{
	/*
	 * If start address is not aligned to cache-line do not
	 * invalidate the first cache-line
	 */
	if (start & (line_len - 1)) {
		printf("ERROR: %s - start address is not aligned - 0x%08x\n",
			__func__, start);
		/* move to next cache line */
		start = (start + line_len - 1) & ~(line_len - 1);
	}

I don't know why (a) the cache invalidation is only done from the next cache line and (b) why this can't be done transparently without printing an error. But currently I'm not keen on fiddling with armv7 caches.

Best regards,
Alexander

Quoted 35 lines · Alexander Stein

Hello Albert,

On Monday 06 July 2015, 09:39:40 wrote Albert ARIBAUD:

Quoted 9 lines

Quoted 3 lines · Alexander Stein

dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to 12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just get error messages about non-cacheline aligned address upon invalidation.

Could it be that code needed to support dcache is not the same for rpi_2's bcm2836 than it is for rpi's bcm2835?

Sure, bcm2835 is a armv6 while bcm2836 is a armv7.

Quoted 3 lines

Anyway: if code properly handles unaligned addresses then it should not throw an error message about it. Can you look into why the error is thrown?

Apparently it does not handle non-cacheline aligned addresses transparently or silently.

Here is the part of the code:

Quoted 12 lines

static void v7_dcache_inval_range(u32 start, u32 stop, u32 line_len)

{
	/*
	 * If start address is not aligned to cache-line do not
	 * invalidate the first cache-line
	 */
	if (start & (line_len - 1)) {
		printf("ERROR: %s - start address is not aligned - 0x%08x\n",
			__func__, start);
		/* move to next cache line */
		start = (start + line_len - 1) & ~(line_len - 1);
	}

Quoted 2 lines

I don't know why (a) the cache invalidation is only done from the next cache line and (b) why this can't be done transparently without printing an error. But currently I'm not keen on fiddling with armv7 caches.

Well, I can see why.

Let's assume were invalidating the second half of a cache line because that's where a buffer starts which we want to force-read from external memory because some device fille dthis buffer with important data.

Now, most probably the compiler and linker will have used the addresses before our buffer to map some variables which may be unrelated to the buffer.

At the time we're told to invalidate the buffer, these variables may be modified in-cache but not yet written out to external memory. If we invalidate the first cache line, then we erase these modifications -- they're lost.

Now, this is an unsolvable problem -- we can't flush these variables before invalidating, because then we would flush the whole cache line, which would overwrite and trash the buffer in external memory.

So anyway, we're doomed; there is nothing we can do -- hence the ERROR message. From the on, we can either just give up and go hang(), or we can try to save whatever can be, skip the half cache line and start invalidating at the next boundary.

(same goes for the last address: it has to be at the end of a cache line, or else we can neither invalidate nor flush.)

Hello Albert,

On Monday 06 July 2015, 23:26:41 wrote Albert ARIBAUD:

Quoted 64 lines

Quoted 35 lines · Alexander Stein

Hello Albert,

On Monday 06 July 2015, 09:39:40 wrote Albert ARIBAUD:

Quoted 9 lines

Quoted 3 lines · Alexander Stein

dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to 12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just get error messages about non-cacheline aligned address upon invalidation.

Could it be that code needed to support dcache is not the same for rpi_2's bcm2836 than it is for rpi's bcm2835?

Sure, bcm2835 is a armv6 while bcm2836 is a armv7.

Quoted 3 lines

Anyway: if code properly handles unaligned addresses then it should not throw an error message about it. Can you look into why the error is thrown?

Apparently it does not handle non-cacheline aligned addresses transparently or silently.

Here is the part of the code:

Quoted 12 lines

static void v7_dcache_inval_range(u32 start, u32 stop, u32 line_len)

{
	/*
	 * If start address is not aligned to cache-line do not
	 * invalidate the first cache-line
	 */
	if (start & (line_len - 1)) {
		printf("ERROR: %s - start address is not aligned - 0x%08x\n",
			__func__, start);
		/* move to next cache line */
		start = (start + line_len - 1) & ~(line_len - 1);
	}

Quoted 2 lines

I don't know why (a) the cache invalidation is only done from the next cache line and (b) why this can't be done transparently without printing an error. But currently I'm not keen on fiddling with armv7 caches.

Well, I can see why.

Let's assume were invalidating the second half of a cache line because that's where a buffer starts which we want to force-read from external memory because some device fille dthis buffer with important data.

Now, most probably the compiler and linker will have used the addresses before our buffer to map some variables which may be unrelated to the buffer.

At the time we're told to invalidate the buffer, these variables may be modified in-cache but not yet written out to external memory. If we invalidate the first cache line, then we erase these modifications -- they're lost.

Now, this is an unsolvable problem -- we can't flush these variables before invalidating, because then we would flush the whole cache line, which would overwrite and trash the buffer in external memory.

So anyway, we're doomed; there is nothing we can do -- hence the ERROR message. From the on, we can either just give up and go hang(), or we can try to save whatever can be, skip the half cache line and start invalidating at the next boundary.

Quoted 2 lines

(same goes for the last address: it has to be at the end of a cache line, or else we can neither invalidate nor flush.)

Thanks for thise detailed explanation. I agree this is really a problem.
But how should this behandled: The raspberry pi messagebox handling sends a message which might have more or less arbitrary length.
I think it might be possible to achieve in every case that those message starts at the beginning of a cacheline. But the end might be
at different positions with different messages sent. You must flush your data to get the firmware actually see this and you must invalidate to eventually read the answer data which is located at the same position. I guess I might just have not hit your described problem in my board (yet).

Best regards,
Alexander

This patchset enables dcache support for Raspberry Pi 1.
First the cache support code was made similar to existing arm1136 code. The invalidate and flush functions were inprovoed to accept also non-cacheline aligned addresses. This reduces the cacheline size knowledge from generic code.

Quoted 5 lines

This patchset enables dcache support for Raspberry Pi 1.
First the cache support code was made similar to existing arm1136 code. The invalidate and flush functions were inprovoed to accept also non-cacheline aligned addresses. This reduces the cacheline size knowledge from generic code.

As mentioned in some other responses, client code must be aware of the cacheline size, so the cache management code shouldn't try to handle misaligned requests, but should error out.

BTW, ALLOC_ALIGN_BUFFER() is probably what you need to fix any misbehaved client code.

On Friday 10 July 2015, 23:17:58 wrote Stephen Warren:

Quoted 7 lines · Alexander Stein

Quoted 5 lines

This patchset enables dcache support for Raspberry Pi 1.
First the cache support code was made similar to existing arm1136 code. The invalidate and flush functions were inprovoed to accept also non-cacheline aligned addresses. This reduces the cacheline size knowledge from generic code.

Quoted 6 lines

As mentioned in some other responses, client code must be aware of the cacheline size, so the cache management code shouldn't try to handle misaligned requests, but should error out.

BTW, ALLOC_ALIGN_BUFFER() is probably what you need to fix any misbehaved client code.

It turns out this is already used everywhere, but the aligned is only 16 instead of 32.

Is there some neat define for the cache size to be used everywhere without defining it in the board config? This would make no sense as according to ARM1176 TRM the cache size is fixed to 32 bytes. So CONFIG_SYS_CACHELINE_SIZE is defined in arch/arm/cpu/arm1176/cpu.c if not defined at board config.

I could use ALLOC_CACHE_ALIGN_BUFFER instead, but this would use an (unnecessary) 64 byte alignment, unless CONFIG_SYS_CACHELINE_SIZE is defined.