From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 6 Jul 2015 23:26:41 +0200 Subject: [U-Boot] [PATCH 0/5] dcache support for Raspberry Pi 1 In-Reply-To: <1635379.iokOHN4OQt@kongar> References: <1436003324-8769-1-git-send-email-alexanders83@web.de> <20150706093940.22ac123b@lilith> <1635379.iokOHN4OQt@kongar> Message-ID: <20150706232641.34728828@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Alexander, On Mon, 06 Jul 2015 20:24:31 +0200, Alexander Stein wrote: > Hello Albert, > > On Monday 06 July 2015, 09:39:40 wrote Albert ARIBAUD: > > On Sat, 4 Jul 2015 11:48:39 +0200, Alexander Stein > > wrote: > > > > > 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. > > > 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: > > 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. 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.) > Best regards, > Alexander Amicalement, -- Albert.