steven, Please feel free to try it, and send out your patch to us.
YH On 6/23/05, Steven J. Magnani <[EMAIL PROTECTED]> wrote: > 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:[EMAIL PROTECTED] > Sent: Wednesday, June 22, 2005 1:20 PM > To: '[email protected]' > 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 > > > > > _______________________________________________ > LinuxBIOS mailing list > [email protected] > http://www.openbios.org/mailman/listinfo/linuxbios > _______________________________________________ LinuxBIOS mailing list [email protected] http://www.openbios.org/mailman/listinfo/linuxbios
