[coreboot] [PATCH] workaround v2 VIA ROMCC breakage

[Eric W. Biederman]

Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> writes:

> Hi Eric,
>
> I'm copying you on this mail because we managed to have ROMCC segfault
> reliably and choke on another piece of code.

Thanks.

> On 16.10.2008 18:36, Rudolf Marek wrote:
>>
>>> +#if 0
>>>      /* Set SPI clock to 33MHz. */
>>>      spireg = (u16 *) (VT8237S_SPI_MEM_BASE + 0x6c);
>>>      (*spireg) &= 0xff00;
>>> +#endif
>>>   
>>
>> This is OK because default is 16MHz, mtrr should handle caching for us.
>
> ROMCC segfaulted on the code above, so a small rewrite may also fix this
> problem. Or we could fix ROMCC.

I would need to get the preprocessed output of that chunk of code
to see how bad that would be to fix.

>>> +#if 0
>>>      if (rom == NULL) {
>>>          print_err("No config data specified, using default MAC!\n");
>>>          n.mac_address[0] = 0x0;
>>> @@ -443,6 +446,7 @@
>>>          n.checksum = 0x0;
>>>          rom = &n;
>>>      }
>>> +#endif
>> The reason why exactly this needs to be handled in rom stage is that
>> the shadow registers needs to be filled _before_ PCI reset, because
>> PCI reset will force the internal microcontroller to reload with this
>> configuration. Its not much documented, only in programming guide,
>> and there is just assembly code and some strange English ;) they
>> really mention that the controller should be reloaded when the device
>> enters D0 via PCIRST#. Dont know if for example some ->D3 and ->D0
>> transition will work or not.
>
> Oh my. That's quite strange hardware. Anyway, it seems that romcc mainly
> barfs on the
> if (rom == NULL)
> check due to unexpected typing. It should be possible to fix this.

Yes.  That sounds like something straight forward.

What is the definition of NULL and the type of rom?

Again preprocessed source is best for debugging this kind of thing.

Eric