[LinuxBIOS] RE: E7501 raminit changes

yhlu yinghailu at gmail.com
Thu Jun 23 17:31:53 CEST 2005


steven,

Please feel free to try it, and send out your patch to us. 

YH

On 6/23/05, Steven J. Magnani <steve at digidescorp.com> 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: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
> 
> 
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>




More information about the coreboot mailing list