config tool + tree enumeration
Eric W. Biederman
ebiederman at lnxi.com
Mon Sep 29 05:46:00 CEST 2003
Stefan Reinauer <stepan at suse.de> writes:
> * Eric W. Biederman <ebiederman at lnxi.com> [030929 00:38]:
> > And until I have a reason I don't see the point, in making
> > a change.
>
> Hm. You are right. With some more tests I found out that this
> solution only fixes the problem occasionally. It seems that
> the chance that it works is higher with the number of tries.
> Really weird.
>
> > Mostly I suspect this is a matter of keeping the irq tables
> > in sync, or something similar where hard codes don't match the dynamic
> > assignments. And if that is the case we need to dig and do a good fix
> > instead of papering over the problem.
>
> If LinuxBIOS hangs during CPU/Northbridge enumeration, can this
> really be a matter of irq tables?
No. My problem is that I don't have a good data point on what
the problem is. And the fact that the problem is not even
consistent is very peculiar.
> I thought that they are touched quite a while later in the setup process.
Yes, much later. Hard codes in the irq tables are one of the
things that could cause problems if the busses were enumerated
in a different order. But not until the kernel has been loaded.
> I suspect it might be connected to the highest bus number set in
> the default resource map, but I did not try more in this direction
> yet.
But it is not consistent?
And what you are hangs. Very, very weird. And this is not with
SST chips?
> Additionally I have Linux moaning that the irq table contains entries
> for a bus that does not exist. It's bus 1, that LinuxBIOS and OpenBIOS
> find really well, only Linux refuses to see it.
And that is also very strange. I need to start synchronizing my
tree with the public one, now that it seems to be working. And I have
some romcc cleanups to do. I finally have the core infrastructure in
place for making inline optional, which should help a lot on the size
issues.
Eric
More information about the coreboot
mailing list