Nico Huber <nico.hu...@secunet.com> 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-
> 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
with inteltool with 800fsb and 1067fsb cpus.
coreboot mailing list: firstname.lastname@example.org