[coreboot] Working on support for the Tolapai

[Noé Rubinstein]

> When trying to make modifications to support other boards,
> I got into similarly seemingly undeterministic failures
This was to be read "When trying to make modification to
support other *RAM modules*".

After further testing, I can confirm that the random failure
problem has *not* been fixed by my SMBus init change.

I still get random failures (i.e. no more serial output, POST
code 80) during the RAM init, and the behaviour changes when
adding or removing print statements.

The Truxton romstage is build with romcc. Is it very likely
that this is a bug with romcc? As it looks like support for
non-CAR might be dropped in the future, I might port the Truxton
romstage to gcc. Any directions/how-to on the matter?
I am not sure what exactly needs to be done, and how much time
it would take.

--
Noé Rubinstein
Proformatique (groupe Avencall) - XiVO IPBX OpenHardware
10 bis, rue Lucien VOILIN - 92800 Puteaux
Tél. : +33 (0)1 41 38 99 60 ext 123
Fax. : +33 (0)1 41 38 99 70

----- Mail original -----
De: "Noé Rubinstein" <nrubinstein at proformatique.com>
À: coreboot at coreboot.org
Envoyé: Jeudi 3 Mars 2011 12:20:43
Objet: [coreboot] Working on support for the Tolapai

Hi,

I'm currently working on improving the support in Coreboot for the Intel Truxton, which is an EVB for Intel EP80579 (codename Tolapai). I'm trying to make it more agnostic with regards to which RAM modules can be used. Right now, it supports only some ECC modules.

I was able to get the board running with a Hynix HYMP564P72BP8-Y5 module, but I got into strange behaviour, as I only got the boot to work after adding two print statements in the RAM init (!). When trying to make modifications to support other boards, I got into similarly seemingly undeterministic failures: that is Coreboot failing during or little before the raminit, at random points (including during the execution of print statements). I'm not currently aware of where the problem comes from; I suppose it might be a compiler problem, or a cache problem, or something else entirely. Any idea about this problem? I don't understand the coreboot build process very well yet; is this part compiled with GCC?

It might not be related, but I have been able to get to the end of the before-ram code by adding the following to enable_smbus in src/southbridge/intel/i3100/early_smbus.c:
        // Taken from the i82801ex code
        /* clear any lingering errors, so the transaction will run */
        outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);

With the info I have at disposition, I will probably be able to get a better support for the RAM init part. As it has been based on DDR1 init code and is used for DDR2, I think it is a good idea to rewrite it or to replace it with something derived from the i945 raminit code. Any thought on the matter?

Thanks,
--
Noé Rubinstein
Proformatique (groupe Avencall) - XiVO IPBX OpenHardware
10 bis, rue Lucien VOILIN - 92800 Puteaux
Tél. : +33 (0)1 41 38 99 60 ext 123
Fax. : +33 (0)1 41 38 99 70

-- 
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot