On 04/13/2012 06:40 AM, Andreas Färber wrote: > Am 12.04.2012 19:24, schrieb Scott Wood: >> On 04/12/2012 11:59 AM, Andreas Färber wrote: >>> Am 10.04.2012 22:04, schrieb Meador Inge: >>>> commit f7aa558396dd0f6b7a2b22c05cb503c655854102 pulled the dcache and >>>> icache >>>> line size initialization inside of a '#if !defined(CONFIG_USER_ONLY)' >>>> block. >>>> This is not correct because instructions like 'dcbz' need the dcache size >>>> initialized even for user mode. >>>> >>>> Signed-off-by: Meador Inge <mead...@codesourcery.com> >>> >>> Looks okay and compiles, >>> >>> Reviewed-by: Andreas Färber <afaer...@suse.de> >>> >>> Scott, are you planning to review this e500 patch? Or should I go ahead >>> and apply? >> >> I'm OK with it, though it may make more sense for USER_ONLY to just pick >> an arbitrary cache line size (probably 32) than to try to imitate a >> specific core. > > Meador, what was your specific problem: The value being zero or not > matching real hardware?
My specific problem was the value being zero. Therefore nothing actually got cleared because the 'dcbz' implementation uses 'dcache_line_size' as an upper bound on a loop. On a side note, the way I actually ran into this was by running a application linked against an optimized version of glibc for e500 that uses 'dcbz' in 'memset'. ld.so wasn't correctly clearing .bss as a result. That was fun to debug :-) > Scott's suggestion would avoid some #ifdef'ery so I'd prefer that if > possible. I'm planning for a PULL later today, so let me know. Sounds good to me. I think the #ifdef stuff is gross, but I wasn't sure of way around it. -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software
