Experiences with Debian Sarge on MPC8xx ?

Experiences with Debian Sarge on MPC8xx ?

[Raphael Bossek]

Hi,

Debian GNU/Linux v3.1 (Sarge) is out so give it a try on my MPC850
running Debian v3.0 for more then 1 year with Denx's 2.4.20 kernel.

It failed with more or less the same reason as described May 2004
in this posting 
http://lists.debian.org/debian-embedded/2004/05/msg00032.html

Things changed since May 2004 but the problem seams to be. I'm using
100% binary compatible Debian GNU/Linux 3.0 (Woody) without any
problems on my MPC860 board with kernel FPU emulation enabled. This
math-emu implementation seams to be stable enought to work with libc6
2.2.5 and very many server application and large C++ application at high
load (our stress tests are really horrible for the compleate system!).

I've also heard from people on IRC that 100% Sarge works for them on
FPU-less MPC boards without trouble. So while I'm investigating the
problem would like to hear some more respond on this issue from
people who spend more time on getting Sarge running with 100% Debian
v3.1 (Sarge) on their MPC8xx environment.

The -msoft-float advice is not what I'm looking for. I'm not sure if
the FPU is responsible for the problem. Maybe the Debian libc6 2.3.2
package is missing something important for the MPC8xx PowerPC (the
cache-line-size is 4 for Debian's libc on PowerPC by default). The
big advantage using a standard distribution is the big number of
precompiled packages. I do not intent to recompile more then 18000
due to this first failed tests.

-- 
Raphael Bossek

Re: Experiences with Debian Sarge on MPC8xx ?

[Wolfgang Denk]

Dear Raphael,

in message <42E0B826.2070800@gmx.de> you wrote:
> 
> Debian GNU/Linux v3.1 (Sarge) is out so give it a try on my MPC850
> running Debian v3.0 for more then 1 year with Denx's 2.4.20 kernel.
> 
> It failed with more or less the same reason as described May 2004
> in this posting 
> http://lists.debian.org/debian-embedded/2004/05/msg00032.html
> 
> Things changed since May 2004 but the problem seams to be. I'm using
> 100% binary compatible Debian GNU/Linux 3.0 (Woody) without any
> problems on my MPC860 board with kernel FPU emulation enabled. This
> math-emu implementation seams to be stable enought to work with libc6
> 2.2.5 and very many server application and large C++ application at high
> load (our stress tests are really horrible for the compleate system!).

I guess you are aware that the FPU emulation is a  nightmare  perfor-
mance-wise  -  you  take  a  kernel  exception  for each and every FP
instruction. FP execution is  several  orders  faster  when  you  use
soft-float  (which,  of  course,  requires  all soft-float libraries,
too).

> I've also heard from people on IRC that 100% Sarge works for them on
> FPU-less MPC boards without trouble. So while I'm investigating the
> problem would like to hear some more respond on this issue from
> people who spend more time on getting Sarge running with 100% Debian
> v3.1 (Sarge) on their MPC8xx environment.

This is probably not a FP issue but may be related to the cache  line
size  and/or  the  infamous  "dcbz"  misbehaviour.  The  standard fix
(removing memset.S when building glibc) has been discussed many times
before; see for example the patches / build scripts for  our  EDK  or
Dan Kegel's crosstool.

> The -msoft-float advice is not what I'm looking for. I'm not sure if
> the FPU is responsible for the problem. Maybe the Debian libc6 2.3.2
> package is missing something important for the MPC8xx PowerPC (the
> cache-line-size is 4 for Debian's libc on PowerPC by default). The

4 what? Bytes? 

> big advantage using a standard distribution is the big number of
> precompiled packages. I do not intent to recompile more then 18000
> due to this first failed tests.

You don't intend to use 18000 packages on your embedded system either
;-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Free markets select for winning solutions."        - Eric S. Raymond

Re: Experiences with Debian Sarge on MPC8xx ?

[Yuli Barcohen]

Try to change cache line size to zero in arch/ppc/kernel/cputable.c

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

Re: Experiences with Debian Sarge on MPC8xx ?

[Kumar Gala]

Does that actually work or are you suggesting something to try?

- kumar

On Jul 22, 2005, at 1:13 PM, Yuli Barcohen wrote:

> Try to change cache line size to zero in arch/ppc/kernel/cputable.c
>
> --  
> ====================================================================== 
> ==
>  Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project  
> Leader
>  yuli@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software,  
> Israel
> ====================================================================== 
> ==
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: Experiences with Debian Sarge on MPC8xx ?

[Yuli Barcohen]

>>>>> Kumar Gala writes:

    Kumar> Does that actually work or are you suggesting something to
    Kumar> try?

This actually works, not with Sarge but with Sid, though glibc version
is the same AFAIK. On MPC8xx, I usually use BusyBox for core utilities
and self-compiled glibc (for performance reasons mentioned by Wolfgang),
and add ready Debian packages for more advanced functions (mail server,
for example). The self-compiled glibc is from the Sid source, so the
problem in it and in the Debian pre-compiled library was the same. I
don't know if it's the only problem on MPC8xx, but on our boards the
"fix" which I described was enough. As we already discussed a couple of
weeks ago, assembler version of memset looks broken for cache line sizes
smaller than (not equal to?) 32. Maybe it's the many times mentioned
dcbz problem. Anyway, the "fix" causes glibc to switch in run time to C
version of memset.

Hope this helps,
-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli@arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================