mpc8xx and ld.so problem

Yuli Barcohen yuli at arabellasw.com
Wed Jul 6 18:58:06 EST 2005


>>>>> 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
========================================================================




More information about the Linuxppc-embedded mailing list