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