[coreboot] Problems porting H8dmr_fam10 to H8qme-2+

Myles Watson mylesgw at gmail.com
Thu Dec 17 18:55:56 CET 2009


On Thu, Dec 17, 2009 at 10:27 AM, Knut Kujat <knuku at gap.upv.es> wrote:

> Myles Watson escribió:
> >
> >
> > On Thu, Dec 17, 2009 at 7:03 AM, Knut Kujat <knuku at gap.upv.es
> > <mailto:knuku at gap.upv.es>> wrote:
> >
> >     Hi,
> >
> >     I did some small changes in Config.lb and Options.lb and then I
> >     compiled
> >     the H8dmr_fam10 board to flash it in a H8qme-2+ board. And of
> >     course the
> >     booting fails :(:
> >
> >     (split)40K table at =dfff0000
> >     0: mmio_basek=00380000, basek=00400000, limitk=00000000
> >     1: mmio_basek=00380000, basek=00480000, limitk=00000000
> >     PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 ?
> >     VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
> >
> >     and here it stucks and doesn't continues.
>
> > I'm not sure what the problem is, but your IO resources aren't getting
> > set properly.  Could you apply this patch and send the output?
> Yes, of course. Please find the new coreboot.log attached.
>
avoid_fixed_resources: PCI_DOMAIN: 0000
avoid_fixed_resources:@PCI_DOMAIN: 0000 10000000 limit 000007ff
avoid_fixed_resources:@PCI_DOMAIN: 0000 10000100 limit ffffffff

It turns out that the problem is before the print statements I inserted.
For some reason, your domain's IO resource is only giving you 0x7ff of IO
space.  That's not enough.  I can't see anywhere in the code where that
would be coming from, so I'm assuming memory corruption.  At this point the
limit should still be 0000ffff.

Could you try increasing the stack and heap sizes?  If that doesn't work
we'll have to find where the limit is getting changed, since it's correct
the first time that the resources are printed.

  PCI_DOMAIN: 0000 links 1 child on link 0 PCI: 00:18.0
  PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags
40040100 index 10000000
  PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff
flags 40040200 index 10000100



> As you can see I added some more printks and it got stuck in
> "set_io_addr_reg" for the first node??
>
With invalid addresses, it's not too surprising that something breaks later.


> Another thing very strange is that at "stage: loading
> fallback/coreboot_ram @ 0x200000 (1048576 bytes), entry @ 0x200000" it
> halts for about 2 minutes, a long time to load 1048576 bytes isn't it?
>
Fam10 seems to have problems with the MTRR settings.  I'm not sure what they
are, but yes it needs to be fixed.  Ward has reported similar long load
times.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20091217/fc8a257f/attachment.html>


More information about the coreboot mailing list