[U-Boot] [PATCH 4/6] davinci_emac: fix for running with dcache enabled

[Anton Staaf]

On Mon, Oct 10, 2011 at 11:45 AM, Anton Staaf <robotboy at chromium.org> wrote:
> On Mon, Oct 10, 2011 at 11:31 AM, Wolfgang Denk <wd at denx.de> wrote:
>> Dear Anton Staaf,
>>
>> In message <CAF6FioWbLz9JKBnj5sJGALtj=bJyLNbFvunNa6FE62y42t6-hw at mail.gmail.com> you wrote:
>>>
>>> > When PPC was building again, I tested it on ARM (which I assumed was
>>> > OK, given that this was Anton's primary architecture). =A0That was when
>>> > I finally gave up, see
>>>
>>> Yes, the patches expose the fact that almost no boards define
>>> CONFIG_SYS_CACHELINE_SIZE.
>>
>> Um...
>>
>> -> ls include/configs/* | wc -l
>> 577
>> -> grep CONFIG_SYS_CACHELINE_SIZE include/configs/* | wc -l
>> 199
>>
>> So that's more than one third of all boards - most of them PPC...
>
> Yes, sorry, I should have said almost no architectures define it, PPC being
> the exception.
>
>>> I am working on a "solution" for this.  My first thought is to add defines
>>> for
>>> CONFIG_SYS_CACHELINE_SIZE in all of the arch cache.h files that
>>> currently do not have them.
>>> This would be all cache.h files other than the PPC one.  But this
>>> could be a huge amount of work
>>> to look up all of the arch cacheline sizes.  So I am thinking of
>>> putting in a wrong, but large power
>>> of two so that boards will build and probably work.  But will
>>> certainly need to be fixed up...
>>
>> Please don't - bogus stuff that appears to be working is known to
>> never get fixed.  Let's rather break the boards - this enforces the
>> needed clean-up.
>
> Yes, that's my feeling as well.
>
>>> Another solution would be to do the above and define
>>> CONFIG_SYS_CACHELINE_SIZE as a
>>> large (128?) value and then indicate that that config is to deprecated
>>> in favor of Mikes suggestion
>>> of using the Linux CACHE BITS defines.  Then we can move boards over
>>> to that mechanism
>>> over time, and in the mean time all boards will compile, and
>>> architectures/boards that correctly
>>> define their cacheline size will function correctly, and
>>> architectures/boards that use the large default
>>> will most likely function correctly...
>>
>> At least a big, dfat build warning must be issued, then (but only one,
>> not a loooooong list).
>
> Would you be OK with a build warning for the lack of definition of
> CONFIG_SYS_CACHELINE_SIZE like I have now if it only happened
> once per board?  I could move it from common.h to a c file that is always
> built.  Perhaps I could add a checks.c file to libgeneric?  I'm not really sure
> if that's the right place for it.  Do you have a suggestion?
>
> This new file would include asm/cache.h and then common.h.  It would then
> have a #ifdef to check for CONFIG_SYS_CACHELINE_SIZE.  So any arch
> that defined it in it's asm/cache.h or any board that defined it in
> it's config file
> would be OK.  All other boards would generate a single compiler warning
> when building that file.
>
> What do you think?
>
> I would have to add a couple of empty asm/cache.h files for the architectures
> that don't currently have them.

So I broke down and am reading all the specs I can find to determine the L1
data cache line sizes for all of the supported architectures in
U-Boot.  But this
means that my patch when it comes will need a good bit of review from people
with more experience from each of these architectures.  In most cases I am
opting to have cache.h define the CONFIG_SYS_CACHELINE_SIZE macro
only if it is not already defined by the board config.  And then only if I can
determine a reasonable upper bound for it's value for an architecture.
 This also
means that my patch will take a little longer to show up, probably tomorrow or
Wednesday would be my guess.

I plan to submit this as a separate patch set from the one that uses the value
of CONFIG_SYS_CACHELINE_SIZE to define the stack allocation macro and
it's use.

Thanks,
    Anton

> Thanks,
>     Anton
>
>> Best regards,
>>
>> Wolfgang Denk
>>
>> --
>> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>> "We don't have to protect the environment -- the Second Coming is  at
>> hand."                                                   - James Watt
>>
>