I think the issue is a buggy _ROM method. Instead of Add (Arg0, Arg1, Local2) it should be Add(Local0, Local1, Local2) :(

It clamps the read length to 0x1000, which is common. But then it goes ahead and sets the length to the total length - offset if the offset + original length (not the clamped length) is too big. No idea how negatives are handled in ACPI either.

Our first request is offset = 0, length = 0x1000, so that should be good. However our second request is offset = 0x1000 length = round_up(remainder, 0x1000). I think this will hit the issue outlined above. Instead of the length being clamped to 0x1000, it will determine that we're overflowing and reset the length to total - offset, which will be way bigger than 0x1000. Since it has the vbios data in multiple 32K regions, this won't return the correct data.

Ben, thoughts on how to detect this?

    Scope (\_SB.PCI0.PEG0.PEGP)
    {
        OperationRegion (VBOR, SystemMemory, 0x9AF9C018, 0x00016004)
        Field (VBOR, DWordAcc, Lock, Preserve)
        {
            RVBS,   32, 
            VBS1,   262144, 
            VBS2,   262144, 
            VBS3,   196608, 
            VBS4,   0
        }
    }


        Method (_ROM, 2, NotSerialized)  // _ROM: Read-Only Memory
        {
            Store (Arg0, Local0)
            Store (Arg1, Local1)
            Name (VROM, Buffer (Local1)
            {
                 0x00                                             /* . */
            })
            If (LGreater (Local1, 0x1000))
            {
                Store (0x1000, Local1)
            }

            If (LGreater (Arg0, RVBS))
            {
                Return (VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
            }

            Add (Arg0, Arg1, Local2)
            If (LGreater (Local2, RVBS))
            {
                Subtract (RVBS, Local0, Local1)
            }

            If (LLess (Local0, 0x8000))
            {
                Mid (VBS1, Local0, Local1, VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
            }
            Else
            {
                Subtract (Local0, 0x8000, Local0)
                If (LLess (Local0, 0x8000))
                {
                    Mid (VBS2, Local0, Local1, VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
                }
                Else
                {
                    Subtract (Local0, 0x8000, Local0)
                    If (LLess (Local0, 0x8000))
                    {
                        Mid (VBS3, Local0, Local1, VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
                    }
                    Else
                    {
                        Subtract (Local0, 0x8000, Local0)
                        If (LLess (Local0, 0x8000))
                        {
                            Mid (VBS4, Local0, Local1, VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
                        }
                    }
                }
            }

            Return (VROM) /* \_SB_.PCI0.PEG0.PEGP._ROM.VROM */
        }

Over IRC, the OP reported that commenting out the fast acpi method does indeed make nouveau load properly.

Created attachment 128903 [details]
Extracted using kernel 3.16

Nouveau works successfully on kernel 3.16.
I copied the bios from /sys/kernel/debug/dri/1/vbios.rom.

This bug was fixed by 5dc7f4aa9d84ea94b54a9bfcef095f0289f1ebda, part of kernel 4.10-rc1 (and potentially some earlier commits also addressed this). Should backport pretty cleanly.

Pawel, if you still have issues, please reopen. If ANYONE OTHER THAN Pawel has issues that look like this, open a fresh issue.