entry16.inc code doubt

Hi,

Could someone please tell me what exactly
these two lines in the entry16.inc for i386 architecture
is doing 
***Extract***
    andl	$0x7FFAFFD1, %eax /* PG,AM,WP,NE,TS,EM,MP = 0 */
    orl	$0x60000001, %eax /* CD, NW, PE = 1 */

***Extract End***

What is the reference for this ..

Thanks and Regards
Deepak

[ron minnich]

On Mon, 21 Apr 2003 [e-mail] wrote:
> ***Extract***
>    andl	$0x7FFAFFD1, %eax /* PG,AM,WP,NE,TS,EM,MP = 0 */
>    orl	$0x60000001, %eax /* CD, NW, PE = 1 */

you really need to get a pengium manual.

Then it will all make sense.

ron

[Deepak Kotian]

> you really need to get a pengium manual.

Where do I get this one. Is it some Linux Man Page.
Could you please give me the link where I can look for
it.

Thanks and Regards
Deepak

----- Original Message ----- 
From: "ron minnich" 
To: 
Cc: 
Sent: Monday, April 21, 2003 9:34 PM
Subject: Re: entry16.inc code doubt
> On Mon, 21 Apr 2003 [e-mail] wrote:
> > ***Extract***
> > andl $0x7FFAFFD1, %eax /* PG,AM,WP,NE,TS,EM,MP = 0 */
> > orl $0x60000001, %eax /* CD, NW, PE = 1 */
>
> you really need to get a pengium manual.
>
> Then it will all make sense.
>
> ron
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

[Ronald G. Minnich]

On Mon, 21 Apr 2003, Deepak Kotian wrote:
> > you really need to get a pengium manual.

pentium

sorry

ron

[Deepak Kotian]

OK, would this hold true for VIA C3 processor, or I need to
change something on it for it.
Basically, would entry16, entry32 would change for VIA C3.
I have intel chipset with this processor.

On the linuxbios tree, I just find a c3 folder with just invd instruction in
one of the files. Is this enough
Please let me know.

Thanks and Regards
Deepak

----- Original Message -----
From: "Ronald G. Minnich" 
To: "Deepak Kotian" 
Cc: 
Sent: Monday, April 21, 2003 11:23 PM
Subject: Re: entry16.inc code doubt
> On Mon, 21 Apr 2003, Deepak Kotian wrote:
> > > you really need to get a pengium manual.
>                          pentium
>
> sorry
>
> ron

SDRAM row page size wierdness

[Richard Smith]

I've finally got LinuxBIOS up and booted to on our Intel 440BX board.

I know the 440BX code was listed as working but after going through a 
lot of the raminit.inc code I don't see how it would have ever worked.

Frirst the DRB register was not getting set properly for bank 1.  It 
always ended up as 00.

The original code set the PGPOL, DRB and RPS registers all in the same 
loop and was very confusing.  Looking through some of the code for the 
other northbridges I saw that these functions were spilt up and much 
easier to follow.  So I wholesale replaced that multi-purpose loop with 
3 seperate routines that I scrounged from the 440gx and Erik's general 
purpose spd code.

Interesting to note that the return value from the 440bx smbus_read_byte 
is exactly opposite from all the other smbus_read_byte implementations.

That fixed the DRB problem.

The next problem has me very confused.  The RPS code sets the RPS for a 
page size of 4kb.  A few debug statements in the RPS routine show that 
4kb is indeed the correct value according to whats in the SPD.

However, It dosen't work.  Doing some compareing with a COTS bios shows 
that register set up for a page size of 8kb.  Hardcode that value in 
after all the spd configure code is done and up it comes.

Any ideas on why I have to feed it a bogus page size to work?  Its not 
registered memory.

I'm trying to gather up a few other sticks and see if it only with this 
brand of memory or in general.

SDRAM row page size wierdness

[ron minnich]

Is it registered dram?

Then the rules change just a bit.

ron

SDRAM row page size wierdness

[Richard Smith]

ron minnich wrote:
> Is it registered dram?
>
> Then the rules change just a bit.

No.. I saw all that funnyness in your RPS routine from the 440gx and 
that was the first thing I looked at.  At least I don't think it 
registered DRAM.  It's not taking the registered dram code path for sure.

SDRAM row page size wierdness

[Richard Smith]

Richard Smith wrote:

Ok...  I got the page size detection worked out.  I'm still confused but 
at least it works.

Going back over the original  440BX code I noticed that it used the 
number of _column_ address rather than the number of row adresses.  At 
first I thought this was a typo (spd loc 4 rather than 3).  This was 
further reenforced by the 440gx code and Eriks general code which use 
the number of row adress bits.

Sounds logical... The number of row adress bits indicating row page size 
  but...

After testing several DIMMs using the row address bits failed in about 
50% of the cases so I started looking back at the column address bits. 
I don't understand why but if you use the number of column address bits 
as a index for what page size to use it works great.

Basically just subtract 8 from the value to shift it down to zero.
8 column bits = 2k page
9 = 4k
10 = 8k

The 440bx dosen't do beyond 8k pages.

I tested as many different DIMMs as I could find here and they all work.

Any ideas on why this would be the case?

SDRAM row page size wierdness

Richard Smith  writes:
> Richard Smith wrote:
>
> Ok...  I got the page size detection worked out.  I'm still confused but at
> least it works.
>
> Going back over the original  440BX code I noticed that it used the number of
> _column_ address rather than the number of row adresses.  At first I thought
> this was a typo (spd loc 4 rather than 3).  This was further reenforced by the
> 440gx code and Eriks general code which use the number of row adress bits.

My code was wrong.
> Sounds logical... The number of row adress bits indicating row page size but...

The number of column address bits determine the size of a row.
the number of row address bits determine the number of rows you have.
> After testing several DIMMs using the row address bits failed in about 50% of
> the cases so I started looking back at the column address bits. I don't
> understand why but if you use the number of column address bits as a index for
> what page size to use it works great.
>
> Basically just subtract 8 from the value to shift it down to zero.
> 8 column bits = 2k page
> 9 = 4k
> 10 = 8k
>
> The 440bx dosen't do beyond 8k pages.
>
> I tested as many different DIMMs as I could find here and they all work.
>
> Any ideas on why this would be the case?

See above.  I think I spotted this a long time ago, but forget to do
anything about it as I don't have a 440 board.

Eric