Level 2 cache activation code?

steven james pyro at linuxlabs.com
Fri Nov 7 09:10:00 CET 2003


Greetings,

Yes, anything non 0 is true. Testing that way (or if(res<0) when the
function is to return a count) generally helps to catch wierdness (in the
bad old days, some functions returned -errno or even errno on error but
always 0 on success, this catches all of those cases).

G'day,
sjames



On Fri, 7 Nov 2003, Svante Signell wrote:

> Steven,
> 
> Thanks for the tip, I'll try adding this in. Preliminary estimations
> with lmbench-2.0 shows like the problems are probably due to the missing
> L2 cache. I'm currently compiling and running running lmbench-3, but
> with an efficient speed of 7MHz instead of 1300MHz, things take time...
> 
> BTW: If one is picky, shouldn't the test be like if(res == -1)? The man
> page of iopl says: 
> On success, zero is returned.  On error, -1 is returned,  and  errno is
> set appropriately. 
> But of course, all values not equal to 0 means "true", right?
> 
> 
> On Thu, 2003-11-06 at 14:59, steven james wrote:
> > 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 
> 

-- 
-------------------------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
-----------------------------------------------------------------------





More information about the coreboot mailing list