Large mmio resources and 4G+ of RAM...

Eric W. Biederman ebiederman at
Tue Jun 1 03:25:01 CEST 2004

Stefan Reinauer <stepan at> writes:

> * Eric W. Biederman <ebiederman at> [040601 09:53]:
> > Essentially.  Although the pci devices don't vanish you likely can't use
> > them because some of their BARS have values that 32bit kernels can't
> > cope with.  lspci should let you see that though.   A 32bit kernel
> > with PAE enabled could code but no one has written the code.
> Are there any drawbacks to that solution? This should be addressed to
> the Linux kernel developers. Given the advantages this brings, this
> would probably something people would like to see.

struct resource {} needs to be defined in terms of u64 instead of
unsigned long.  I know just that tweak was discussed and there were
some problems with that.

> > I don't have a problem with adding an option to disable this for 32bit
> > kernels.  I am just tired of optimizing 64bit machines for 32bit
> > kernels.
> The silver bullet would be an option in the cmos option table to trigger
> the one or the other behaviour. 

Right that is what I was thinking.

> Or maybe it is enough to just put the
> PCI BARs into 32bit address space whenever it fits there, taking the
> amount of RAM into regard.

Except for some very small filters that starts requiring a filter
that is too smart.  I think ultimately it is going to the bridge
bars that are going to limit me.  So I may only be able to apply
this to prefetchable memory regions.  But that should still cover
the large mmio regions with 64bit BARs.

> I agree it does not make sense to _optimize_ for 32bit kernels.
> Essentially there are two groups of potential LinuxBIOS users in this
> case: Those with small amounts of RAM (ie amd64 based embedded
> solutions) might use 32bit code because it's easy to test it on many
> PCs. Those with large amounts of RAM don't want to use a 32bit kernel
> anyways. With more than about 1G of RAM 32bit Linux performance breaks
> down noticably compared to the 64bit variant.

Interesting.  Most of my customers have compute intensive apps and I
don't think see the break down anywhere near that soon.


More information about the coreboot mailing list