Attempt to porting coreboot to Gigabyte ga-945gcm-s2l

[Arthur Heymans]

Hi

I'm trying to port coreboot to the gigabyte ga-945gcm-s2l, which has a
945gc northbridge, a ich7 southbridge and a ite it8718f sio. I'm trying
all this with a 1067fsb cpu, so in that last aspect there is no
precedent in coreboot.

I encountered some raminit issues where the MCHBAR(CLKCFG) was
incorrectly written, but this was fixed in
https://review.coreboot.org/#/c/16940/.

Right now I'm stuck in smm_init in southbridge/intel/i82801gx/smi.c.
The boot process completely hangs when wbinvd() is called which supposed
to "Write Back and Invalidate Cache" according to
http://x86.renejeschke.de/html/file_module_x86_id_325.html.

What does this mean? Did the raminit not work?

--
Kind regards

Arthur Heymans

[Zoran Stojsavljevic]

Hello Arthur,

CPUID 1067x? Penryn? https://en.wikipedia.org/wiki/Penryn_(microprocessor)
?!

It is long time off any radar screen for INTEL IOTG support, I can tell to
you this... Started production in 2007! :-(( WTH you need Coreboot on this
one?

"The WBINVD instruction is a privileged instruction. *When the processor is
running in protected mode, the CPL of a program or procedure must be 0 to
execute this instruction.* This instruction is also a serializing
instruction (see "Serializing Instructions" in Chapter 8 of the IA-32 Intel
Architecture Software Developer's Manual, Volume 3)."

Question to you: do you execute this instruction (WBINVD) in Ring 0
(kernel) mode? If you do, and it still hangs, I have for you a good
suggestion: try to replace WBINVD with INVD and see if you'll hang (simple
logic stands behind what I read there:
http://x86.renejeschke.de/html/file_module_x86_id_325.html).

If you hang: your problem is for sure/100% NOT raminit (in other words MRC);
If you do NOT hang, and continue: raminit (MRC) might be (but not
certainly???) your problem. If you hang later (while accessing DDRAM), then
it is obvious! ;-)

Good luck with this one,
Zoran

On Sun, Oct 9, 2016 at 6:50 PM, Arthur Heymans <[e-mail]> wrote:
> Hi
>
> I'm trying to port coreboot to the gigabyte ga-945gcm-s2l, which has a
> 945gc northbridge, a ich7 southbridge and a ite it8718f sio. I'm trying
> all this with a 1067fsb cpu, so in that last aspect there is no
> precedent in coreboot.
>
> I encountered some raminit issues where the MCHBAR(CLKCFG) was
> incorrectly written, but this was fixed in
> https://review.coreboot.org/#/c/16940/.
>
> Right now I'm stuck in smm_init in southbridge/intel/i82801gx/smi.c.
> The boot process completely hangs when wbinvd() is called which supposed
> to "Write Back and Invalidate Cache" according to
> http://x86.renejeschke.de/html/file_module_x86_id_325.html.
>
> What does this mean? Did the raminit not work?
>
> Arthur Heymans

[Nico Huber]

Hi Arthur,

On 09.10.2016 18:50, Arthur Heymans wrote:
> Hi
>
> I'm trying to port coreboot to the gigabyte ga-945gcm-s2l, which has a
> 945gc northbridge, a ich7 southbridge and a ite it8718f sio. I'm trying
> all this with a 1067fsb cpu, so in that last aspect there is no
> precedent in coreboot.
>
> I encountered some raminit issues where the MCHBAR(CLKCFG) was
> incorrectly written, but this was fixed in
> https://review.coreboot.org/#/c/16940/.
>
> Right now I'm stuck in smm_init in southbridge/intel/i82801gx/smi.c.
> The boot process completely hangs when wbinvd() is called which supposed
> to "Write Back and Invalidate Cache" according to
> http://x86.renejeschke.de/html/file_module_x86_id_325.html.

This is just a synchronization point. The wbinvd() is there to ensure
that the memcpy() above has reached real RAM before the program con-
tinues.

As this fails right after resources have been assigned to all devices, I
suspected a resource conflict but couldn't find any trouble in your log.

Another thing that can cause trouble is the MTRR configuration. I have
no idea in which state they are / should be in your case, though.
> What does this mean? Did the raminit not work?

This close to the end of ramstage I wouldn't expect trouble from a bad
raminit (you have already written/read plenty things to/from RAM). But
still, this could suffer from some wrong configuration done in romstage.

Regards,
Nico

[Arthur Heymans]

Nico Huber <[e-mail]> writes:
> Hi Arthur,
>
> This is just a synchronization point. The wbinvd() is there to ensure
> that the memcpy() above has reached real RAM before the program con-
> tinues.
>
> As this fails right after resources have been assigned to all devices, I
> suspected a resource conflict but couldn't find any trouble in your log.
>
> Another thing that can cause trouble is the MTRR configuration. I have
> no idea in which state they are / should be in your case, though.

It really is a raminit issue. I tested with a 800MHz fsb (does not even get
to ramstage) and a 533MHz fsb cpu which just works (this is a 1067fsb cpu with
tape on bsel0 pin to make it select 533fsb). So unless 945gc raminit
gets fixed, this port is quite useless.

This i945 raminit.c seems to have a lot of code specific for 667fsb
(laptops only) and 533fsb (Intel d945gclf atom board).

I guess I'll have to run vendor through serialICE and see how MCHBARS are configured
with inteltool with 800fsb and 1067fsb cpus.

Kind regards
-- 
Arthur Heymans