From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 12 Apr 2016 02:59:27 +0200 Subject: [U-Boot] [PATCH] efi_loader: Always flush in cache line size granularity In-Reply-To: <20160412003959.GW13577@bill-the-cat> References: <1459755138-173508-1-git-send-email-agraf@suse.de> <570AD2BA.609@suse.de> <570AD432.9090404@suse.de> <570AD571.8010305@denx.de> <20160412003959.GW13577@bill-the-cat> Message-ID: <570C486F.7060906@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/12/2016 02:39 AM, Tom Rini wrote: > On Mon, Apr 11, 2016 at 12:36:33AM +0200, Marek Vasut wrote: > >> On 04/11/2016 12:31 AM, Alexander Graf wrote: >>> >>> >>> On 11.04.16 00:24, Andreas F?rber wrote: >>>> Am 04.04.2016 um 09:32 schrieb Alexander Graf: >>>>> The cache line flush helpers only work properly when they get aligned >>>>> start and end addresses. Round our flush range to cache line size. It's >>>>> safe because we're guaranteed to flush within a single page which has the >>>>> same cache attributes. >>>>> >>>>> Reported-by: Marek Vasut >>>>> Signed-off-by: Alexander Graf >>>>> --- >>>>> lib/efi_loader/efi_runtime.c | 3 ++- >>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c >>>>> index 22bcd08..40acec0 100644 >>>>> --- a/lib/efi_loader/efi_runtime.c >>>>> +++ b/lib/efi_loader/efi_runtime.c >>>>> @@ -194,7 +194,8 @@ void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map) >>>>> #endif >>>>> >>>>> *p = newaddr; >>>>> - flush_dcache_range((ulong)p, (ulong)&p[1]); >>>>> + flush_dcache_range((ulong)p & ~(CONFIG_SYS_CACHELINE_SIZE - 1), >>>>> + ALIGN((ulong)&p[1], CONFIG_SYS_CACHELINE_SIZE)); >>>> >>>> dragonboard410c_defconfig fails to build with this due to undefined >>>> CONFIG_SYS_CACHELINE_SIZE. Do we need to #ifdef here or is the >>>> dragonboard410c at fault for not defining it? >>> >>> Some USB drivers use it unconditionally, but I guess the dragonboard401c >>> doesn't enable USB. >>> >>> Let me come up with a more compatible version. >> >> This version is fine, dragonboard needs fixing. Every single board must >> define CONFIG_SYS_CACHELINE_SIZE . > > Yeah... but this isn't quite the right time to break all of: > arm: + mx28evk integratorap_cm720t at91sam9261ek_dataflash_cs3 > at91sam9261ek_dataflash_cs0 integratorap_cm946es mx28evk_nand > integratorcp_cm1136 at91sam9x5ek_nandflash > at91sam9xeek_dataflash_cs1 at91sam9260ek_dataflash_cs0 > at91sam9260ek_dataflash_cs1 at91sam9g20ek_nandflash > meesc_dataflash at91sam9260ek_nandflash mx35pdk xfi3 > at91sam9263ek_dataflash_cs0 at91sam9xeek_dataflash_cs0 > at91sam9xeek_nandflash bg0900 highbank sansa_fuze_plus mx25pdk > mx23evk at91sam9x5ek_mmc igep0030_nand m28evk > at91sam9g20ek_dataflash_cs1 at91sam9g20ek_dataflash_cs0 > integratorcp_cm946es at91sam9n12ek_nandflash > at91sam9n12ek_spiflash da850_am18xxevm devkit3250 > at91rm9200ek_ram picosam9g45 at91sam9n12ek_mmc > integratorcp_cm926ejs integratorap_cm920t > at91sam9m10g45ek_nandflash sc_sps_1 omapl138_lcdk mx28evk_spi > integratorap_cm926ejs at91sam9rlek_mmc apx4devkit mx23_olinuxino > at91sam9x5ek_spiflash at91sam9g10ek_nandflash > at91sam9g10ek_dataflash_cs3 at91sam9g10ek_dataflash_cs0 > at91sam9g20ek_2mmc_nandflash apf27 stv0991 > at91sam9261ek_nandflash at91rm9200ek at91sam9g20ek_2mmc > da850evm_direct_nor at91sam9263ek_norflash meesc > at91sam9263ek_dataflash at91sam9m10g45ek_mmc armadillo-800eva > at91sam9x5ek_dataflash da850evm usb_a9263_dataflash > at91sam9rlek_nandflash mx28evk_auart_console > at91sam9263ek_norflash_boot integratorcp_cm920t > at91sam9263ek_nandflash at91sam9rlek_dataflash > (and maybe a few more, toolchain here craps out due to libgcc problems), Ha, libgcc ... :-( > and we've talked about this before too I think. The right long term > answer is to borrow the logic of arch/arm/mm/Kconfig and asm/cache.h > from the kernel to get the right size, always. For the short term, > we'll just work-around it. I thought we fixed these cache issues already, but that was on v7 only, dang. Now it is v4/v5 which broke. -- Best regards, Marek Vasut