Hurray, I now have 3.5Gb. I NOPed the bios code that sets the D_LCK bit, which allows me to change TOLUD in my grub2 module. I also had to remap a bunch of other PCI memory ranges and reprogram the MTRR registers. Now the only thing that's wrong is I can't suspend/resume when 3.5 Gb is on. I don't know if the fix is as simple as editing the ACPI tables or if I need to hack the SMM code in the BIOS. Currently, I believe 3.5Gb is the most I can get, contrary to 3.7Gb I said earlier. This is because the GeForce's 256Mb memory window needs to be mapped aligned at [e0000000, f0000000). I don't think [f0000000, 100000000) is an option because there are so many devices that use that range and some aren't remappable (e.g. ROM, ACPI region @ff000000). If anyone can think of a way to get more space, I'd like to hear it. On Sun, Aug 9, 2009 at 6:22 AM, Yale Zhang<yzhang1985@xxxxxxxxx> wrote: > OK. I've managed to solve the problem. I looked at dmesg, which > complained about MCFG inconsistencies, which led me to edit the ACPI > MCFG table and set address to 0xf0000000, end bus to 63, and fix the > checksum. I also changed some e0000000 values in the DSDT table to > f0000000, but I don't think that's essential. Hurray, Vista boots > correctly. Now, I'll have to wait for my USB floppy so I can start > flashing my BIOS to change TOLUD register. > > If anyone knows which register locks TOLUD on i945PM, please tell me. > So far, I suspect it's D_LCK, but don't see it being written in the > disassembled BIOS. > > On Fri, Aug 7, 2009 at 5:22 PM, Yale Zhang<yzhang1985@xxxxxxxxx> wrote: >> Fellow hackers, >> >> I'm trying to mod my laptop hardware configuration to support > 3 Gb RAM. >> I'm quite convinced it can support up to 3.7 Gb. >> Here's how I'm doing it. >> >> 1. Increase TOLUD (highest DRAM address for mem controller to decode) >> register on i945PM chipset. Currently, it's C0000000. >> 2. Remap GeForce's PCI_BASE_ADDRESS_1 (frame buffer) from 0xc0000000 - >> 0xd0000000 to 0xe0000000 - 0xf0000000. >> 3. Change the PCIX bridge's prefetchable memory range (base, limit >> registers) to match Geforce's frame buffer. >> 4. Remap PCIX extended configuration space MMIO space from 0xe0000000 - >> 0xf0000000 to 0xf0000000 - 0xf4000000 (done by writing i945 register) >> 5. Override the BIOS e820 memory map. Initially, I just used the memmap= >> boot arguments. Later I hard coded a new map into grub2's >> grub_machine_mmap_iterate(). grub2 by default overrides the BIOS's int15, >> e820 with this new map. >> >> Here's my old physical memory map: >> >> BIOS-provided physical RAM map: >> BIOS-e820: 0000000000000000 - 000000000009f800 (usable) >> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) >> BIOS-e820: 00000000000dc000 - 00000000000e4000 (reserved) >> BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved) >> BIOS-e820: 0000000000100000 - 00000000bfee0000 (usable) >> BIOS-e820: 00000000bfee0000 - 00000000bff00000 (ACPI NVS) >> BIOS-e820: 00000000bff00000 - 00000000c0000000 (reserved) >> BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) PCIX >> extended config space >> BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) >> BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) >> BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) MCH bar >> registers >> BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) >> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >> BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) >> >> (all other PCI devices - NICs, USB, etc use ~16MB MMIO space around >> 0xd0000000) >> >> new memory map: [e0000000, f0000000) changes to [f0000000, f4000000) only >> >> Step 1 requires moding the BIOS, which I'll have to wait on until I learn >> how to flash a bricked BIOS. >> >> I've done steps 2 to 5 and it frees 256Mb of address space as expected. On >> Debian, lspci reports >> the GeForce's frame buffer is mapped at 0xe0000000 and graphics works >> correctly. >> >> When I try to boot Vista, I get a BSOD 0.5s after the logo screen saying >> the BIOS is not ACPI compliant. >> are my guesses: >> 1. Grub didn't hook int15, e820 - I'm not sure if this is done for >> chainloader boots. I guess I can test >> this by doing a chainloader boot for Linux and executing int15, e820. >> 2. PCI BIOS reports inconsistent results from my changes (assuming Windows >> uses it) >> 3. ACPI tables contain inconsistent data (e.g. PCIX extended configuration >> base). >> >> I will be very disappointed if I have to modify the PCI BIOS or ACPI tables. >> Does anyone know what could be wrong? >> >> Thanks >> Yale >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
