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@proformatique.com À: coreboot@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