FP and signal 4

FP and signal 4

[- Reyneke]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]


Hi all,

Has anyone come across any floating point issues in the new powerpc kernel branch with regards to 44x? I'm seeing programs (i.e. init/busybox) generating signal 4 (illegal instruction) exceptions. If I compile a 2.6.25 kernel with the CONFIG_MATH_EMULATION option set, then everything works OK. 

Using a 440EPx (has a onchip FPU) with the ELDK 4.0 ppc_4xxFP toolchain for all apps/kernel/fs. 

Kind of follows on from this thread: http://ozlabs.org/pipermail/linuxppc-embedded/2007-June/027363.html


 Regards
   Jan

_________________________________________________________________

http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/

[-- Attachment #2: Type: text/html, Size: 908 bytes --]

Re: FP and signal 4

[Josh Boyer]

On Wed, 4 Jun 2008 14:43:48 +0000
- Reyneke <reynekejunk@hotmail.com> wrote:

> 
> Hi all,
> 
> Has anyone come across any floating point issues in the new powerpc kernel branch with regards to 44x? I'm seeing programs (i.e. init/busybox) generating signal 4 (illegal instruction) exceptions. If I compile a 2.6.25 kernel with the CONFIG_MATH_EMULATION option set, then everything works OK. 

I've not seen that.

> Using a 440EPx (has a onchip FPU) with the ELDK 4.0 ppc_4xxFP toolchain for all apps/kernel/fs. 

440EPx should get the FPU enabled at runtime.  We use a virtual PVR to
do the APU/FPU init.  What does your cpu node look like in your DTS
file for your board?

josh

Re: FP and signal 4

[Stefan Roese]

On Thursday 05 June 2008, Josh Boyer wrote:
> > Has anyone come across any floating point issues in the new powerpc
> > kernel branch with regards to 44x? I'm seeing programs (i.e.
> > init/busybox) generating signal 4 (illegal instruction) exceptions. If I
> > compile a 2.6.25 kernel with the CONFIG_MATH_EMULATION option set, then
> > everything works OK.
>
> I've not seen that.
>
> > Using a 440EPx (has a onchip FPU) with the ELDK 4.0 ppc_4xxFP toolchain
> > for all apps/kernel/fs.
>
> 440EPx should get the FPU enabled at runtime.  We use a virtual PVR to
> do the APU/FPU init.  What does your cpu node look like in your DTS
> file for your board?

And please use the dtc "-b 0" option for creating the dtb file. Without it the 
virtual PVR setup doesn't work.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
=====================================================================

RE: FP and signal 4

[- Reyneke]

Aaah - looks like that was it. Works OK now with CONFIG_MATH_EMULATION un-s=
et. For the record - cpu node looks as follows:



		cpu@0 {
			device_type =3D "cpu";
			model =3D "PowerPC,440EPx";
			reg =3D ;
			clock-frequency =3D ; /* Filled in by u-boot */
			timebase-frequency =3D ; /* Filled in by u-boot */
			i-cache-line-size =3D ;
			d-cache-line-size =3D ;
			i-cache-size =3D ;
			d-cache-size =3D ;
			dcr-controller;
			dcr-access-method =3D "native";
		};

Thanks for the help.


>
> On Thursday 05 June 2008, Josh Boyer wrote:
>>> Has anyone come across any floating point issues in the new powerpc
>>> kernel branch with regards to 44x? I'm seeing programs (i.e.
>>> init/busybox) generating signal 4 (illegal instruction) exceptions. If =
I
>>> compile a 2.6.25 kernel with the CONFIG_MATH_EMULATION option set, then
>>> everything works OK.
>>
>> I've not seen that.
>>
>>> Using a 440EPx (has a onchip FPU) with the ELDK 4.0 ppc_4xxFP toolchain
>>> for all apps/kernel/fs.
>>
>> 440EPx should get the FPU enabled at runtime. We use a virtual PVR to
>> do the APU/FPU init. What does your cpu node look like in your DTS
>> file for your board?
>
> And please use the dtc "-b 0" option for creating the dtb file. Without i=
t the
> virtual PVR setup doesn't work.
>
> Best regards,
> Stefan
>

_________________________________________________________________

http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/=

Re: FP and signal 4

[Stefan Roese]

On Thursday 05 June 2008, - Reyneke wrote:
> Aaah - looks like that was it. Works OK now with CONFIG_MATH_EMULATION
> un-set.

Great.

I hope "-b 0" is set by default in recent dtc versions. If not we should 
really do this (I already mentioned this to David Gibson before). This is a 
nasty bug on 440EPx which was not so easy to find.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
=====================================================================

Re: FP and signal 4

[Jon Loeliger]

Also sprach Zarathustra und Stefan Roese:
>
> I hope "-b 0" is set by default in recent dtc versions.

Und Git antwortete:

commit 548767f42eb00a2bac6f2a1361b7fd49f7b76908
Author: David Gibson <david@gibson.dropbear.id.au>
Date:   Fri May 16 13:22:57 2008 +1000

    dtc: Rework handling of boot_cpuid_phys
    
    Currently, dtc will put the nonsense value 0xfeedbeef into the
    boot_cpuid_phys field of an output blob, unless explicitly given
    another value with the -b command line option.  As well as being a
    totally unuseful default value, this also means that dtc won't
    properly preserve the boot_cpuid_phys field in -I dtb -O dtb mode.
    
    This patch reworks things to improve the boot_cpuid handling.  The new
    semantics are that the output's boot_cpuid_phys value is:
        the value given on the command line if -b is used
    otherwise
        the value from the input, if in -I dtb mode
    otherwise
        0
    
    Implementation-wise we do the following:
        - boot_cpuid_phys is added to struct boot_info, so that
    structure now contains all of the blob's semantic information.
        - dt_to_blob() and dt_to_asm() output the cpuid given in
    boot_info
        - dt_from_blob() fills in boot_info based on the input blob
        - The other dt_from_*() functions just record 0, but we can
    change this easily if e.g. we invent a way of specifying the boot cpu
    in the source format.
        - main() overrides the cpuid in the boot_info between input
    and output if -b is given
    
    We add some testcases to check this new behaviour.
    
    Signed-off-by: David Gibson <david@gibson.dropbear.id.au>