[coreboot] [PATCH] workaround v2 VIA ROMCC breakage

[Carl-Daniel Hailfinger]

On 16.10.2008 19:59, Eric W. Biederman wrote:
> 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.
>
>   
>>>> +#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.
>   

The error message is:
"arithmetic type expexted"

romcc -mcpu=c3 -O auto.E -o auto.inc

Input file is attached.

Regards,
Carl-Daniel

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: auto.E
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081016/3ff4b830/attachment.ksh>