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@digidescorp.com] Sent: Wednesday, June 22, 2005 1:20 PM To: 'linuxbios@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