>>>>> Tom Rini writes:
Yuli> [...deleted...]
Jason> Ha. Funny. The glibc powerpc maintainer doesn't want any
Jason> embedded fixes in the mainline. Last I checked, that was for
Jason> 'the tools vendors' to fix.
Jason> "We won't work around processor bugs" is their philosophy.
Yuli> [...deleted...]
Yuli> I investigated the problem a bit when I had trouble with a
Yuli> self-compiled glibc a year or so ago. IIRC, I found bug in the
Yuli> memset code, not in the chip. The code was just wrong for
Yuli> cache line sizes not equal to 32. So memset.S is good for 60x
Yuli> series (PQII included) but for 8xx it fails. We use dcbX
Yuli> instructions in some kernel drivers and since we never had any
Yuli> problems with those drivers I'm a bit surprised to hear that
Yuli> all 8xx chips have got that bug.
Tom> It's also OK on a multiple of 32, iirc, but not smaller. And
Tom> using the information the kernel does export would be too slow.
Tom> Or at least no one figured out a good way to do it, userspace
Tom> side.
IMHO the cache line size from cputable is not used in the kernel but
only passed to the ELF interpreter. I did not want to re-build glibc so
I changed the entry for mpc8xx to pass 0 instead of 16. This disabled
the assembler implementation of memset and since then all our
mpc8xx-based boards work properly. In any case, since it looks like a
coding bug and not CPU errata, maybe the glibc maintainer would be
willing to fix it?
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli at arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
