[coreboot] [PATCH] workaround v2 VIA ROMCC breakage

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Oct 16 18:47:50 CEST 2008


Hi Eric,

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


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.


>> +#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.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the coreboot mailing list