[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:[e-mail]] 
Sent: Wednesday, June 22, 2005 1:20 PM
To: '[e-mail]'
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

[yhlu]

steven,

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

YH

On 6/23/05, Steven J. Magnani  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:[e-mail]]
> Sent: Wednesday, June 22, 2005 1:20 PM
> To: '[e-mail]'
> 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
> [e-mail]
> http://www.openbios.org/mailman/listinfo/linuxbios

[Steve Magnani]

From: yhlu
> Please feel free to try it, and send out your patch to us.

Yh Lu,

Without knowing _why_ you added the stop grant configuration, I can't tell
whether it is something that needs to happen all the time, needs to happen
only when the system is to run at CL 2.0, or doesn't really need to happen
at all. All I know is that my board seems to run OK at CL 2.0 without
changing the default stop grant ratio.

If there's any insight you can provide, I would have a better idea how to
merge this into the reworked E7501 code.

Thanks,
Steve