[LinuxBIOS] RE: E7501 raminit changes

[Steven J. Magnani]

A correction: I'm pretty sure now my RCOMP_MMIO problems were due to
"A20 hell", not TOLM. 

Does anyone know if de-asserting A20M# is enough to cause A20 to behave
normally? On our board, after we force A20M# high, the system continues
to behave as if A20 is always zero. We're using an embedded board, so
there is no keyboard controller in the mix - I/O port 0x92 is enough to
toggle A20M#. 

Some of the Intel documentation mentions an "A20M# interrupt" in
passing, but there are no specifics. Is there something else that
firmware needs to do after driving A20M# high?

Color me confused,

Steve


-----Original Message-----
From: Steven J. Magnani [mailto:steve at digidescorp.com] 
Sent: Wednesday, June 22, 2005 1:20 PM
To: 'linuxbios at openbios.org'
Subject: E7501 raminit changes


Yh Lu,

I noticed that you added code to the E7501 raminit to change the mapping
between system bus and southbridge stop grants from the default of 1:1
to 2:1 when the file is compiled with CAS_LATENCY defined to CAS_2_0.

Is the stop grant change needed only for CL 2.0, or should it be applied
to both 2.0 and 2.5? If the former, I'll put it in the function that
configures the CAS latency based on SPD info (i.e. make the
configuration change programmatic rather than table-driven). If the
latter, I'll move the code you added outside the #if block it's
currently in.

Also, I believe you mentioned earlier (re: s2735 is totally broken) that
you were seeing a weird reset in the raminit code. On my platform I was
getting an exception during RCOMP configuration (Ram1.00), which I
traced to the definition of RCOMP_MMIO as 0x100000. I think because that
address lies below the default Top of Low Memory that accesses to that
space weren't going to the RCOMP registers. Redefining RCOMP_MMIO as
0x80000000 fixed that problem for me.

Regards, 
Steve Magnani
www.digidescorp.com