[coreboot] [PATCH] workaround v2 VIA ROMCC breakage

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Oct 17 02:26:02 CEST 2008


On 17.10.2008 02:17, Corey Osgood wrote:
> On Thu, Oct 16, 2008 at 7:32 PM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 17.10.2008 01:14, 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.
>>>>
>>>>
>>>> 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.
>>>>
>>>>         
>>> Likely.  I'm not certain because that function is never called in the
>>>       
>> output
>>     
>>> you sent me.
>>>
>>> I was going to suggest changing it to just if (!rom) and then it started
>>> complaining about addresses of auto variables not being supported.
>>>
>>> So ultimately putting #ifndef ROMCC around that whole function looks
>>> like the right thing to do.
>>>
>>>       
>> That indeed sounds like a solution, thanks. The code in question is
>> sometimes compiled with ROMCC and sometimes with GCC. Fortunately, the
>> only case where the code is called is a single mainboard which uses CAR
>> and GCC anyway.
>>     
>
>
> There's another issue: 0x<something>ULL in vt8237r.h causes ROMCC to die,
> too (garbage at the end of integer constant, iirc). My proposal was going to
> be to move the vt8237_early_network_init funciton along with the 3 #defines
> that cause the problem to another file, and only have that file included by
> the k8-based boards. I don't remember why I trashed it, probably because we
> really should just get CAR going in v2 (do we have/need a disable_car for C7
> in v2?)
>   

I added a special case for ROMCC in the 0x...ULL constants in vt8237r.h.
Please see r3664.
The remaining segfault is being investigated by Eric.

Regards,
Carl-Daniel

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





More information about the coreboot mailing list