Level 2 cache activation code?

[steven james]

Greetings,

To run that code inside linux, you need to add a call to iopl to allow
direct hardware access like:

res = iopl(3);
if(res) {
	report_error();
	exit(-1);
}

or something to that effect.
G'day,
sjames


On Thu, 6 Nov 2003, Svante Signell wrote:

> 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
> > 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------