Re: menuconfig FPU question.
> Michael:
> the gcc compiler is free to choose usage of floating-point without
> "-msoft-float" flag being set. I am concerned that in the standard
> usage, Linux might save context of floating point or such. This
> command would lock the processor.
Sure, that's why the kernel code either checks for presence of a FPU
before saving FPU state, and skips that step if no FPU is found, or may be
forced to never even compile in FPU state stuff if CONFIG_MATH_EMU_ONLY is
set. The kernel in itself never uses floating point operations other than
the fsave/frestore/fmoveml operations on user context switches. Using any
floating point ops in the kernel would destroy FPU state on system calls
without a user context switch.
The processor would only be locked on machines without FPU, and on these
machines either FPU emulation support or CONFIG_MATH_EMU_ONLY should be
defined.
Are there any situations not covered by these configurations that I
overlooked?
> In short: To insure that floating point is unused, set this flag.
Not necessary. With regard to FPU state handling this is taken care of by
the kernel. At least in those kernels with FPU emulation support, and in
all Mac kernels.
> I am still unable to generate a kernel that works. I need to know,
> in simple terms, what steps that are not covered by the HOWTO or
> the kernel docs.
I'd need to know what kernel version you try to compile, and where
you got the source from, what patches you applied, etc. Please note that
linux-m68k@lists.linux-m68k.org is more appropriate for kernel level
problems than debian-68k.
> I am running potato and the system works, but I need to change the
> kernel
> for some new hardware that I want to use. I also wish to setup kernel
> debugging. Any ideas or directions would be most welcomed.
To change the level of debugging info produced by the kernel, use dmesg.
To direct kernel debug messages to the console in addition to the syslog,
see /etc/syslog.conf. To direct kernel messages to the serial port, use
the console=ttyS0 (for instance) kernel option. If you seriously consider
using the kernel gdb stub that may be compiled in (to attach your kernel
to another machine running gdb over the serial interface), you should
talk to people on linux-m68k (I've never encountered a situation where use
of kgdb was the only way to debug).
Hope this helped,
Michael
Reply to: