<div dir="ltr">On Thu, Oct 16, 2008 at 7:32 PM, Carl-Daniel Hailfinger <span dir="ltr"><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net">c-d.hailfinger.devel.2006@gmx.net</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">On 17.10.2008 01:14, Eric W. Biederman wrote:<br>
> Carl-Daniel Hailfinger <<a href="mailto:c-d.hailfinger.devel.2006@gmx.net">c-d.hailfinger.devel.2006@gmx.net</a>> writes:<br>
><br>
><br>
>> Hi Eric,<br>
>><br>
>> I'm copying you on this mail because we managed to have ROMCC segfault<br>
>> reliably and choke on another piece of code.<br>
>><br>
>><br>
>> On 16.10.2008 18:36, Rudolf Marek wrote:<br>
>><br>
>>>> +#if 0<br>
>>>>      /* Set SPI clock to 33MHz. */<br>
>>>>      spireg = (u16 *) (VT8237S_SPI_MEM_BASE + 0x6c);<br>
>>>>      (*spireg) &= 0xff00;<br>
>>>> +#endif<br>
>>>><br>
>>>><br>
>>> This is OK because default is 16MHz, mtrr should handle caching for us.<br>
>>><br>
>> ROMCC segfaulted on the code above, so a small rewrite may also fix this<br>
>> problem. Or we could fix ROMCC.<br>
>><br>
>><br>
>><br>
>>>> +#if 0<br>
>>>>      if (rom == NULL) {<br>
>>>>          print_err("No config data specified, using default MAC!\n");<br>
>>>>          n.mac_address[0] = 0x0;<br>
>>>> @@ -443,6 +446,7 @@<br>
>>>>          n.checksum = 0x0;<br>
>>>>          rom = &n;<br>
>>>>      }<br>
>>>> +#endif<br>
>>>><br>
>>> The reason why exactly this needs to be handled in rom stage is that<br>
>>> the shadow registers needs to be filled _before_ PCI reset, because<br>
>>> PCI reset will force the internal microcontroller to reload with this<br>
>>> configuration. Its not much documented, only in programming guide,<br>
>>> and there is just assembly code and some strange English ;) they<br>
>>> really mention that the controller should be reloaded when the device<br>
>>> enters D0 via PCIRST#. Dont know if for example some ->D3 and ->D0<br>
>>> transition will work or not.<br>
>>><br>
>> Oh my. That's quite strange hardware. Anyway, it seems that romcc mainly<br>
>> barfs on the<br>
>> if (rom == NULL)<br>
>> check due to unexpected typing. It should be possible to fix this.<br>
>><br>
><br>
> Likely.  I'm not certain because that function is never called in the output<br>
> you sent me.<br>
><br>
> I was going to suggest changing it to just if (!rom) and then it started<br>
> complaining about addresses of auto variables not being supported.<br>
><br>
> So ultimately putting #ifndef ROMCC around that whole function looks<br>
> like the right thing to do.<br>
><br>
<br>
</div></div>That indeed sounds like a solution, thanks. The code in question is<br>
sometimes compiled with ROMCC and sometimes with GCC. Fortunately, the<br>
only case where the code is called is a single mainboard which uses CAR<br>
and GCC anyway.</blockquote><div><br>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?)<br>
<br>-Corey <br></div></div></div>