On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu <yinghai at kernel.org> wrote: > On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury <steve at snewbury.org.uk> > wrote: >>>>>>>> >>>>>>>> pci 0000:03:08.0: BAR 15: can't assign mem pref (size >>>>>>>> 0x18000000) >>>>>>> Ah! Not enough space for the bridge window!:( >>>>>>> >>> >>>>>> please append pci=norom ... >>> >>>>> That worked. ?Except of course the radeon driver can't POST the >>>>> ?card without the ROM! :-P >>>> Can the ROM resource be mapped above 4G? >>> I didn't really think that through, obviously it can't because >>> it's not on a 64-bit capable bridge. ?I wonder though, could it be >>> shadowed then disabled early before the IOMEM? >> I see there's "#if 0"'d helper functions for exactly that in rom.c. >> They've been disabled since 2007! > > solution could be one of three: > 1. when bridge support 64bit pref, will not allocate rom bar in bridge > pref resource. > ====> patch: rom_pref.patch > > 2. unconditionally to make rom bar allocation in bridge non-pref range. > ====> patch: rom_no_pref.patch
missed attach rom_no_pref.patch > Looks like BIOS and at least one of other OSes is doing that. > > I can not find the the history why ROM res is with PREFETCH bit set. > Maybe Linus has some idea about that. > > 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but > that could fail. > ? so could hack it like a. disable bar 0x10 and steal BAR address, > then set 0x30 to that address then copy ROM to ram. > ? after that, disable rom again and set back address to 0x10. > ? You try to update radeon_get_bios() to achieve that. > > ? ? ?Yinghai -------------- next part -------------- A non-text attachment was scrubbed... Name: rom_no_pref.patch Type: application/octet-stream Size: 839 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120415/953419b1/attachment.obj>
