To summarize: The easy way is to use 2G. The preferred way would be to mimic mrc behaviour and reboot after finding the correct size.
On 2016-06-06 09:36 PM, ron minnich wrote:
I'm getting the sense here that reasonably modern CPUs can easily handle the 2G hole. From what I've seen, it would not cause trouble for older CPUs because they're most likely to be in small systems that are not likely to have more than 2G memory anyway (I'm thinking of the vortex).
The 2G hole seems like a reasonable way go to.
ron
On Mon, Jun 6, 2016 at 1:01 AM Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
I think one can go with 2GB MMIO hole.
Agreeing here. We have PAE. Non-ancient 32bit kernels should support and use it, for both security reasons (nox support requires PAE page table format) and accessing physical address space above 4G.
The PCIe > 4GB is a question, I don't think Windows have good support for this.
Depends on the version. Recent windows versions have no problems handling it. WinXP throws a BSOD though in case it finds a 64bit mmio window described in _SB.PCI0._CRS ...
cheers, Gerd
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
On Mon, Jun 6, 2016 at 12:52 PM Patrick Rudolph siro@das-labor.org wrote:
To summarize: The easy way is to use 2G. The preferred way would be to mimic mrc behaviour and reboot after finding the correct size.
I'm not sure it's "easy vs. preferred" so much as - simple that has no known failure cases (yet). - best that requires that we have another variable we have to store in flash
At least to me, it's not as cut and dried as easy vs. preferred. The preferred way adds a lot of moving runtime parts, and we'll need to cover for the case that the stored variable gets damaged somehow. The easy way is a runtime constant, which I kind of like.
If the "easy" way always works, i.e. we never find a case where it causes a problem, then it seems superior to me.
ron
Patrick Rudolph wrote:
The easy way is to use 2G.
Do this now.
The preferred way would be to mimic mrc behaviour and reboot after finding the correct size.
As Ron writes, I don't think it's neccessarily preferable to do something significantly more complex, if it isn't actually significantly better.
Keep it simple, so to say. Thanks!
//Peter