On Mon, Oct 10, 2011 at 11:45 AM, Anton Staaf <robot...@chromium.org> wrote: > On Mon, Oct 10, 2011 at 11:31 AM, Wolfgang Denk <w...@denx.de> wrote: >> Dear Anton Staaf, >> >> In message >> <CAF6FioWbLz9JKBnj5sJGALtj=bjylnbfvunna6fe62y42t6...@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: w...@denx.de >> "We don't have to protect the environment -- the Second Coming is at >> hand." - James Watt >> > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot