Level 2 cache activation code?

[Svante Signell]

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
>