All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] efi_loader: Always flush in cache line size granularity
Date: Tue, 12 Apr 2016 02:59:27 +0200	[thread overview]
Message-ID: <570C486F.7060906@denx.de> (raw)
In-Reply-To: <20160412003959.GW13577@bill-the-cat>

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 <marex@denx.de>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>> ---
>>>>>  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

  reply	other threads:[~2016-04-12  0:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-04  7:32 [U-Boot] [PATCH] efi_loader: Always flush in cache line size granularity Alexander Graf
2016-04-04  7:56 ` Marek Vasut
2016-04-10 22:24 ` Andreas Färber
2016-04-10 22:31   ` Alexander Graf
2016-04-10 22:36     ` Marek Vasut
2016-04-12  0:39       ` Tom Rini
2016-04-12  0:59         ` Marek Vasut [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-04-11 21:20 Alexander Graf
2016-04-13 12:53 ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=570C486F.7060906@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.