Hi,
Sorry for taking up this thread again but now I have made a test of the l2_cache activation code and have some further questions.
The files put together to make things build are l2_cache.c, printk.c, vsprintf.c, subr.c and corresponding header files from the linuxbios CVS tree. For subr.c I had to add an include (#include <sys/io.h>) to get outb defined for linking. The result so far is a segfault, in the cache_enable() inline assembly routine in l2_cache.c)
0. How to test this code after a _slow_ boot outside the BIOS? Is single user mode sufficient, i.e. init 1?
1. How are these printk statements supposed to work? Is the output directed to some system logfile, like kern.log? How to define this logfile etc. What to change if I want to log debug outputs to the standard out and/or standard err? I don't find any output when running the main program, neither in the system log files or on the screen.
2. Any special compiler and linker switches needed, like -nostdinc, -nostdlib, -nostartfiles, etc? Your build system is Python based, right, so I cannot easily look at Makefiles in the CVS tree.
3. I found where the program halts with gdb and compiling with debug set. One way to trace is single stepping in gdb etc. What is supposed to happen when the DEBUG is defined in l2_cache.c?
4. You state that the L2 cache stuff is only needed for P2 CPUs, not for P3 type CPUs, such as Coppermine or Tualatin. I'm testing with a Celeron 2 CPU (Tualatin), which is of P3 type. What if the BIOS does not recognise the CPU and disables the L2 cache? People claim that AMI BIOSes work this way. It the enabling code sufficient to make things work.
5. If the slowness is not due to a disabled L2 cache (how to test this properly btw?), can the problems be solved by tying with the mtrr or microcode update code?
6. Maybe the problem is still hardware related, like the on-board voltage regulator for the CPU is not working properly, even if there are no indications at all from the on board sensors. However, if the problems are software related and can be solved, do you think it is feasible to replace the AMI BIOS with LinuxBIOS? The probability of getting an updated BIOS from MSI supporting Coppermine and Tualatin processors is probably zero.
Thanks, Svante
On Wed, 2003-10-01 at 15:40, ron minnich wrote:
On Wed, 1 Oct 2003, Svante Signell wrote:
i) Does LinuxBIOS work for 440BX-based mother-boards, single and dual? Downloading the code from CVS shows support for Intel L440GX+ and a patch for linux-2.4.13, not 440BX or kernels later than 2.4.13. Also, I did not find anything about MSI mainboards.
single are tested. Dual I don't know.
ii) Does the cache activation code work for Mendocino, Coppermine, Tualatin and newer Intel processors? Will it work for the VIA C3 Nehemiah?
It was only needed for PII. Coppermine and later -- "Just works". It is extremely cpu-dependent.
iii) How much of the boot process in GNU/Linux the BIOS responsible for? I thought that the kernel was only dependent on the BIOS for a few functions, such as different HW initialisations: CPU, memory, disks, etc compared to Windows 9x etc. Any pointers?
that's about right.
I will try. Which files do I need in addition to src/cpu/p6/l2_cache.c?
none. You have to turn that back into a main() but it should be fine.
With risks I meant the chance of being left with a dead motherboard... I'm always nervous when flashing the BIOS that something will happen, for example a sudden power loss, regardless of where the BIOS originates from.
never do this kind of work without a spare bios part. Never.
BTW: Why is this work called LinuxBIOS (except maybe for historical reasons). Will other OSes (eg GNU/Hurd) boot with LinuxBIOS now or in the future? Maybe then something like FreeBIOS should be used instead.
It was called linuxbios for a simple reason: linux was going to be the bios. linux would be in flash, linux would boot the oses.
Small flashes have caused changes in course in some cases, but the name has stuck anyway. Now that vendors have joined in, changing the name would be hard.
ron