[coreboot] [PATCH] workaround v2 VIA ROMCC breakage

[Corey Osgood]

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?)

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081016/8dbc4433/attachment.html>